Subscribe • Previous Issues

What Startups Taught Me About the Next Layer of AI Infrastructure

A little while back I wrote about how teams use reinforcement learning (RL) to make agents reliable. Since then I keep bumping into startups where RL is not a research footnote or a feature buried in the stack. It is central to what they are building. I know of more than 25 at last count and still climbing, and in some cases RL is basically the product. It is still early, and much of the current tooling is aimed at frontier labs, neo labs, and sophisticated AI teams. Still, there is enough signal to think that some of the tools and lessons will eventually trickle down to the rest of us. At this point I treat my own RL timelines the way I treat horoscopes, entertaining but not binding. What I will say instead is that this particular wave has startups, products, and customers around it, which the previous periods mostly did not.

The New Infrastructure for Learning by Doing

The common thread is that almost all of these startups are reacting to the same frustration. Frontier models are smart but unreliable the moment you ask them to do real, multi-step work. RL is the lever they pull to turn raw capability into dependable behavior, whether the target is a coding agent, a support bot, or a humanoid robot.

But none of them are really selling RL as a magic algorithm. They’re building the missing machinery around it, and that machinery has two hard parts. The first is giving a model somewhere to practice, which is why so many are in the business of simulated environments and training gyms. The second, and trickier, part is scoring. Did the agent finish the task, follow the rules, pick the right tool, avoid a shortcut that games the metric? A surprising amount of this market is really about graders, verifiers, and the tooling to catch an agent cheating its own reward.

From there the goals split. Some startups build RL environments for frontier labs. Some build post-training platforms for companies that want specialist models. Some focus on continuous learning from production traces. Others carry RL into robotics, industrial control, and logistics. The common thread is simple enough to state plainly. If you can define the task, create a safe place to practice, and score the result, RL has something to work with.

Where Learning by Doing Pays Off

The first commercial cluster is exactly where you would expect. Coding, software engineering, ML engineering, security, and infrastructure tasks show up again and again because they come with built-in ways to score progress. Code can compile or fail. Tests can pass or fail. A sandbox can reveal whether the agent’s action changed the system in the intended way. The feedback is still imperfect, but it is much cleaner than asking a human to grade every step from scratch.

The second big cluster is computer use and enterprise work. These are agents that operate browsers, spreadsheets, CRMs, ticketing systems, internal tools, finance software, documents, and knowledge bases. This is where the difference between a demo and a production agent becomes painfully obvious. A model that can explain a workflow is not the same as an agent that can execute it, recover from mistakes, and satisfy a company’s standards.

Then there’s a smaller but striking set of use cases that leave the screen entirely: robots learning to walk and grip, data-center cooling, freight routing. The wider pattern is that RL is showing up wherever teams can create a loop. There has to be a task, a place to attempt it, a way to observe what happened, and a score that is close enough to what the user actually cares about. That pattern applies to coding agents, enterprise research, support workflows, financial modeling, medical reasoning, industrial cooling, logistics, and robotics. The domains differ, but the recipe is surprisingly consistent.

When Does This Reach the Rest of Us

The question I keep coming back to is when this becomes usable by a broader set of AI teams. Right now, a lot of the tooling still assumes serious technical depth. You need to define environments, write rewards, inspect rollouts, catch reward hacking, and connect the training loop to real systems. That is not casual weekend work. But when this many startups are building environments, post-training platforms, verifiers, agent gyms, and RLOps tooling, it is hard not to expect some of the abstractions to become simpler.

In one sense, the trickle-down has already started. The startups helping companies post-train or customize foundation models are bringing pieces of RL tooling into enterprise settings today. That’s RL tooling reaching real businesses today, not in some hypothetical future. The next step is not that every AI team becomes an RL research lab. It is that more teams get practical tools for defining the work they care about, measuring success, and improving models against those signals over time.

The AI Bubble Risk Map

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

Your CLI Was Built for Humans, Not Agents

There’s a friendly debate among developers about how to give AI agents reliable ways to use external tools, data, and services so they can do useful work beyond generating text. One side favors CLIs, or Command-Line Interfaces, where agents run text commands against tools like git, aws, jq, duckdb and internal scripts. The other side favors MCP, or Model Context Protocol, which gives agents a structured way to discover tools, authenticate, and call services through defined schemas. This may seem confined to coding agent, but the tradeoffs apply equally to anyone deploying agents in operations, finance, customer success, or any workflow where agents need to touch real systems. Once an agent starts taking action, its interface with the outside world is no longer just a technical detail. It becomes a critical decision point for security, cost, and governance, regardless of whether that agent is writing code or managing customer data.

CLI: Fast, Familiar, and Sharp-Edged

The strongest case for CLI is that it is familiar, flexible, and cheap. First, AI models have been trained on enormous quantities of shell scripts, developer documentation, and terminal content, which means they already understand tools like git, docker, and kubectl, without any special configuration, and that familiarity translates directly into reliability and lower error rates. Second, CLI output is composable: an agent can pipe the output of one command directly into another to filter, aggregate, or reshape data before it enters the model’s working memory. Finally, the token efficiency advantage is real and measurable. Loading a single MCP server’s full tool schema can consume tens of thousands of tokens before any useful work begins, whereas CLI tools require zero upfront context cost and agents can discover a tool’s capabilities on demand using its built-in --help flag. The catch is that CLI access can be too powerful. Giving an agent raw shell access without sandboxing, credential isolation, and approval gates makes it incredibly difficult to prevent unauthorized changes to files and networks.

The MCP Case for Agents

MCP’s advocates have a direct response to the CLI-first view: CLI doesn’t account for how most AI is actually consumed in the world. The majority of people interacting with AI agents do so through browser-based chat interfaces or mobile apps where running shell commands is simply not an option, and many business tools have no CLI equivalent at all. For those contexts, MCP fills a genuine gap: it gives agents a self-describing interface where the agent discovers which tools are available and how to use them upon connecting, without needing to guess command syntax or parse documentation. Unlike CLI, MCP includes built-in OAuth authentication, per-user permissions, and audit trails that satisfy enterprise security requirements.

The main criticism is overhead. Poor MCP implementations can load huge tool schemas before useful work begins, burning tokens, adding latency, and leaving less room for reasoning. MCP can also introduce server failures, authentication friction, and harder debugging. The practical lesson is that MCP needs good interface design: smaller task-level tools, progressive disclosure, schema filtering, and gateways that show agents only what they need.

Your CLI Was Built for Humans, Not Agents

An agent can learn command syntax. The harder problem is that most CLIs were designed for humans, not software agents operating under time, token, and safety constraints. We easily overlook these flaws because humans are great at filling in the blanks. We can guess missing steps from bad manuals, decode vague error messages, and realize on our own when a tool requires us to log in before showing its options. An agent pays a concrete cost for every one of those gaps: repeated discovery loops, wasted tokens, fragile text parsing, and unnecessary interruptions asking the user what to do next. The CLI didn’t change. The user did.

The practical response is to treat CLI agent-readiness as something you can measure and improve, not just assume. An open-source project called CLIARE (CLI Agent Readiness Evaluation) does exactly this. It probes the actual installed binary, not your documentation, records what happens, and produces a scored report across six dimensions: whether commands are findable and navigable, whether valid invocations can be constructed, whether commands complete without hanging, whether bad inputs fail with clear errors, whether machine-readable output modes are available and actually work, and whether read-only probes stay read-only. The result is a scorecard you can run, track across releases, and share with the teams building agents on top of your tooling. That shifts interface quality from a guessing game into a measurable metric.

This matters well beyond coding agents. Companies can expose real operational authority through CLIs: deployments, finance workflows, database jobs, cloud control planes, support scripts, analytics pipelines, and internal platforms. If agents are going to touch those surfaces, the relevant question is not just “does a CLI exist?” It is “can the agent understand and use it without guessing?” AI teams exposing CLIs to agents should try CLIARE, or at least borrow its core idea: make the command surface measurable, versioned, parseable, and explicit about preconditions, outputs, side effects, and risk.

Match the Interface to the Risk

I would not treat this as a religious choice between CLI and MCP. The better question is what kind of authority the agent is being given, and on whose behalf it is acting. Use CLI when the workflow is local, composable, inspectable, and already lives close to the terminal: code, tests, logs, files, data inspection, build systems, mature vendor tools, and internal scripts. But if agents will use that CLI repeatedly, use CLIARE to measure the surface before relying on it.

Use MCP when the workflow is hosted, multi-user, permissioned, or tied to SaaS systems where OAuth, consent, scoped access, and audit trails matter. In both cases, raise the bar when the agent can touch money, identity, production systems, customer data, or irreversible state. The common design rule is simple: expose the task, not the whole system. Keep the interface small, prefer parseable outputs, separate reads from writes, log consequential actions, and require approvals for operations that cannot be easily undone. Transport choice matters. Interface design matters more.

The AI Developer Productivity Debate: A Field Guide

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

Agents Need Maps, Not Bigger Context Windows

Like everyone else, I’ve been enjoying the steady improvement in coding agents and the tooling around them, from frameworks and harnesses to evaluation suites. But the more I talk with teams actually deploying agents in enterprises, the more I circle back to plumbing. Agents need data integrations and infrastructure built for them, a theme I explored in a piece on rethinking databases for agents. I’ve also written about using knowledge graphs (GraphRAG) to improve accuracy and reduce hallucinations, which is especially important in high-stakes applications. The persistent problem has been that most teams don’t have a knowledge graph, and the few that do struggle to keep it current. A new system I recently came across is aimed squarely at that gap.

Automating Graph Construction and Maintenance

I recently spoke with Andrew Moore, CEO of Lovelace, former head of Google Cloud AI, and former dean of Carnegie Mellon’s School of Computer Science. Lovelace’s Elemental platform turns enterprise data into structured context engines that AI agents can navigate and investigate. I think “knowledge graph” is still a reasonable term here, although “context graph” may be closer to the point. This is not a graph built mainly for a human analyst browsing nodes on a screen. It is designed for agents that need to answer questions too large, messy, or time-sensitive for ordinary search, basic RAG, or stuffing more raw documents into a context window.

Elemental ingests whatever you have: relational tables, PDF files, news feeds, JSON fragments, even satellite imagery and other multimodal sources. Everything gets converted into a common intermediate form that eventually becomes nodes and relationships in a graph. The platform automates much of the construction and maintenance of these graphs. A graph with a thousand nodes can tolerate a human in the loop, but once you’re at many millions of facts, any step that depends on a person checking whether two records refer to the same company simply collapses. Too many enterprise AI projects die in the six months of data wrangling that comes before any actual AI work, and removing that toil is the whole point.

For an agent, a context graph gives it a map of the enterprise and the surrounding world. A bank investigating exposure to a sanctioned shipping company might need to connect ownership records, trade data, vessel movements, subsidiaries, legal filings, customer relationships, and recent news. Vector search can find relevant documents, but these questions often require following relationships across many entities and events. That is where a graph-shaped context layer becomes useful.

Graphs for Agents, Without a Graph Database

Elemental is designed around four steps: data ingestion, entity resolution, graph construction, and agent-facing tool access. I covered ingestion above, but one constraint is worth adding: the system has to work without assuming clean schemas, consistent naming, or a single source of truth.

Entity resolution is the problem of deciding when different records refer to the same real-world thing. “IBM,” “International Business Machines,” an internal vendor ID, a legal entity in a filing, and a name in a PDF might all refer to the same company, or they might not. The same issue appears with people, ships, aircraft, accounts, subsidiaries, addresses, products, assets, and events. Anyone can prototype an entity resolution system in a weekend. Making one that scales, handles multiple languages, adapts to entirely new entity types, and updates as new information arrives is brutally hard. Lovelace built its own engine and goes well beyond text matching. I half-jokingly told Andrew that the entity resolution engine alone could be a standalone product, given how many applications live or die on getting this right.

Auditability is just as important. In regulated or high-stakes settings, the system needs to show where a fact came from, how it was linked to other facts, and what version of the graph existed when an agent produced an answer. In plain English, that means lineage, provenance, and version control: how a fact moved through the system, what evidence supports it, and what the graph believed at a point in time. That matters if a regulator, customer, or internal reviewer asks why an agent flagged a transaction, recommended an investigation, or dismissed an alert. “The model said so” will not be enough.

Retrieval is where the graph becomes more than a data catalog. In a serious graph, a single node can have hundreds of thousands of links, so a naive “show me everything within two hops” query explodes into billions of paths and grinds to a halt. Elemental takes a different route. It reframes a question like “who is most affected by this event?” as a probability problem, then uses randomized algorithms and other graph-theory tricks to surface the strongest connections without walking every path. The result is approximate rather than mathematically exact, but it returns confident, ranked answers over millions of nodes in under a second. That trade is well worth making, because the alternative is an LLM trying to reconcile contradictory probabilistic evidence in its head, which language models are genuinely bad at.

Another interesting design choice is that Elemental does not rely on a graph database as the core storage layer. The data is exposed to agents as a graph, but the persistence layer underneath is custom. The reason is simple. Traditional graph databases are very useful, but they were not built for this particular job: broad, high-speed inference across tens of millions of nodes.

Why Private Graphs Need Public Context

Lovelace also brings another asset to the table: YottaGraph. Think of it as a large, continuously updated graph of the public world, covering companies, people, places, events, filings, sanctions records, and the movements of ships and aircraft. This is useful because internal enterprise data rarely tells the whole story. YottaGraph would be hard to replicate because it requires continuous ingestion from many sources, entity resolution at scale, and a lot of operational discipline. Importantly, the enrichment flows inward. Public context can augment a company’s private graph, but Lovelace does not share one customer’s data with other organizations.

Lovelace isn’t alone in using graphs to give agents better context, and I expect to see much more activity here. There is also a funny twist. GraphRAG was promoted heavily by graph database vendors, but some of the more interesting graph systems for agentic AI may not use graph databases at all. Whatever we end up calling these things, knowledge graphs, context graphs, or context engines, the underlying idea of structured, auditable context for agents is becoming hard to ignore.

OckBench: The Cost of Getting the Right Answer

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The Data Compliance Problem AI Teams Keep Ignoring

I’ve avoided writing about copyright and AI. Not because it isn’t important, but because it felt like a legal sideshow compared to the engineering and business questions I find more interesting. That’s gotten harder to justify. There is also something mildly funny about naming my podcast The Data Exchange years ago, because I believed data markets would become central to technology, and then mostly ducking this corner of the data conversation. The data question is now central to how AI systems are built, how they compete, and how they create risk. You can’t talk seriously about any of that without eventually bumping into who owns the stuff these models are trained on.

For AI teams, data is no longer just raw material. One recent economics paper estimated that the value of data missing from official GDP figures amounts to about 4% of GDP on average, and closer to 6% in more recent years. More interesting for companies is the relative value of their own operational data: transaction logs, usage records, support tickets, product telemetry, and customer interactions. That internal data can be more informative than public web data because it captures how a real business actually works. For AI builders, the practical implication is simple: the data sitting inside your company may be more strategically valuable than anything you could scrape from the open web.

The Data Supply Chain Problem

The first practical issue is provenance: knowing where training data came from, what rights apply, and whether it can be inspected or reconstructed later. That used to sound like paperwork. It now looks like core infrastructure. What a model knows, where it performs well, where it breaks down, and what legal exposure it carries are all shaped by the data it was trained on. Pre-training is the broad phase where a model absorbs patterns from large collections of text, images, code, books, journalism, and other sources. Post-training is where you steer the model toward specific tasks, behaviors, and domains using narrower, more curated datasets. Both phases are data strategy questions as much as engineering questions. For most teams, the immediate action is not to audit a trillion-token pre-training corpus. It is to get serious about the smaller, higher-value datasets they use to adapt, evaluate, and deploy models.

Memorization adds a second layer of risk. A model does not need to act like a database to create trouble. Under the right prompts, especially when material appears many times in training data, it may reproduce protected text, code, lyrics, images, or paywalled content too closely. That makes copyright risk a lifecycle issue, not just a training-data issue. Hosted models give providers more room to monitor, filter, and rate-limit suspicious behavior. Released model weights are harder to control. Either way, teams need to test for verbatim reproduction, near-duplicates, and outputs that could substitute for the original work.

Guarding Your Post-Training and Fine-Tuning Pipelines

Most AI teams aren’t doing pre-training. They’re taking a foundation model and adapting it: fine-tuning on domain data, building instruction datasets, running human feedback loops, assembling evaluation suites, or wiring up retrieval pipelines. That’s where the real data work happens for the majority of developers, and it comes with its own provenance problems. The data you use to customize a model, customer support logs, internal documents, expert annotations, licensed content, third-party datasets, needs the same documentation discipline as any other part of the stack. Where did it come from? What rights apply? Was it collected with appropriate consent? Can you reproduce it if challenged? These questions matter whether you’re fine-tuning a vertical copilot or building an evaluation harness, and the answers are often murkier than teams expect. A lightweight data bill of materials can help: a record of each dataset, its source, license terms, consent status, known restrictions, and intended use.

There’s also a technical risk that’s easy to underestimate in post-training contexts. Fine-tuned models can memorize training examples more readily than large pre-trained models, partly because the datasets are smaller and examples may repeat. A customer-facing model fine-tuned on proprietary documents, licensed text, or third-party content could reproduce that material verbatim in ways that create real liability. That risk doesn’t disappear after training ends. Output monitoring matters: similarity detection, content flagging, and policies for handling prompts that look like attempts to extract protected material should be part of any production deployment. No single control handles all of it, and the teams most likely to get caught flat-footed are the ones who assumed that using someone else’s base model meant the data compliance problem was already solved.

Who Owns the Fuel That Runs These Models

We are also seeing the rise of a formal data licensing market, where major publishers and content platforms sign deals with AI labs. While this reduces legal uncertainty for those who can afford it, it also threatens to create a massive moat for wealthy incumbents. Large AI firms can afford broad or exclusive deals that smaller labs, startups, researchers, and open-source projects cannot.

The legal landscape is also evolving unevenly around the world. The U.S. still relies heavily on case-by-case fair use arguments. Europe is pushing more toward transparency, opt-outs, documentation, and compliance processes. Some Asia-Pacific jurisdictions appear more permissive for computational analysis, but global deployment complicates everything. A model trained in one place can be used, challenged, or regulated somewhere else. In practice, many companies will opt to satisfy the strictest plausible standard, especially if they sell to large enterprises or regulated industries.

This is why AI and copyright no longer feel like a legal sideshow to me. They are part of a larger question about how data markets will actually work: who gets paid, who gets access, who can prove what they used, and who can afford the cleanest inputs. The industry still has to find a workable balance between adaptation and attribution. Data is no longer just exhaust from the internet or residue from business operations. It is becoming one of the main assets, bottlenecks, and fault lines in AI. The teams treating it as a compliance checkbox are going to find that out the hard way.

The Runtime Pattern Behind AI Agents

Claude Code to Cursor: a poem

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The Hybrid AI Stack Is Coming for the Pricing Power of OpenAI and Anthropic

OpenAI and Anthropic are going public while still capturing much of the money spent on foundation-model usage. But deployment patterns are starting to tell a more complicated story. Companies are building hybrid model portfolios, using proprietary models where convenience, support, and frontier capability matter, while turning to open-weights models where cost, privacy, customization, and deployment control matter more. As teams get better at operating multiple models, the single-vendor AI stack will look less like the default and more like a transitional phase.

What Open Weights Give You And What They Do Not

The economics are hard to ignore. In an earlier piece, I argued that the CFO has become the CTO, the Chief Token Officer. That framing applies directly here. Proprietary APIs are still useful for prototyping, broad assistants, and difficult reasoning tasks. But once a workflow becomes stable and high volume, token-based pricing starts to feel like a tax on scale. Open-weights models can cut unit costs sharply for repeatable work such as document processing, classification, extraction, internal search, customer support, and summarization. The savings are not automatic. Infrastructure and engineering costs have to be absorbed first. But for organizations running millions of daily inferences, the case can become compelling much sooner than many executives expected.

The appeal is not just lower cost. Open-weights models give enterprises more control over where data goes, how models are adapted, and which version is running in production. That matters for banks, insurers, healthcare organizations, manufacturers, software companies, and any business handling sensitive records, proprietary code, contracts, customer conversations, or regulated data. A model that runs in a private cloud, on-premises environment, or approved regional infrastructure can be easier to govern than one accessed only through a third-party endpoint. With open-weights models, enterprises can select a model version, test it, approve it, and keep running it. This is valuable for regulated or high-stakes systems where silent behavior changes create audit and compliance problems. Fine-tuning and post-training lets teams adjust model behavior without retraining the whole system. RAG, or retrieval-augmented generation, lets a model consult a curated internal knowledge base before answering. Together, these patterns allow smaller models to perform well on company-specific workflows.

The barriers are just as practical. Switching to open weights is not like swapping an API key. Proprietary platforms package hosted endpoints, scaling, documentation, security features, enterprise support, and contractual accountability. Open-weights models shift more of that burden to the buyer. Teams need GPU planning, model serving, inference optimization, monitoring, evaluation, logging, access control, fallback paths, and cost tracking. The total cost of ownership is easy to underestimate because the API bill disappears, but the operational work does not. In some organizations, infrastructure and specialized engineering talent can become the dominant cost. Open weights can improve economics, but only for teams mature enough to run them well.

The governance issues are even harder to wave away. Proprietary platforms usually include safety layers and enterprise risk support. Open-weights models often require companies to build those controls themselves. Input/output guardrails, red-team testing, incident response, secure artifact management, and model provenance all become first-class engineering concerns. Tools such as Heretic show why this matters. Safety guardrails can be stripped from open-weights models quickly, which raises obvious compliance and misuse risks. Legal teams also have real work to do. “Open-weight” does not mean unrestricted. Licenses may limit commercial use, redistribution, scale, geography, or specific capabilities. And when these models are used for code generation, companies need processes for scanning outputs for vulnerabilities and license conflicts.

The New Enterprise Model Stack

The next phase is not open versus closed. It is workload-specific model selection. A routine classification task can go to a smaller open-weights model. A sensitive internal search workflow can run inside private infrastructure. A difficult reasoning problem can be escalated to a proprietary frontier model. This is the real meaning of hybrid model portfolios. The architecture is no longer about picking one best model. It is about building a routing and governance layer that can evaluate requests, choose the right model, monitor cost and quality, and replace models when needed. I already see this in my own coding workflow. My O² toolkit, using opencode and OpenRouter, is useful precisely because different models are better for different jobs.

This hybrid approach becomes even more critical as we move toward agentic workflows. When you build autonomous agents that continuously run loops, call tools, and handle background tasks, your token consumption scales dramatically. If you run these entire multi-step workflows on premium proprietary endpoints, your monthly API bill will explode. Instead, a smarter architecture uses smaller, local open-weights models to handle the routine, repetitive steps in an agent’s loop, while escalating only the high-stakes decisions or complex reasoning tasks to closed frontier models. This setup also keeps the agent’s sensitive tool integrations and internal system commands within your own secure network rather than routing them through external APIs. The catch is that agents make the control layer harder to build. Every action needs to be logged, auditable, and ideally reversible, and most teams deploying agents have not built that infrastructure yet.

This shift in workload routing has uncomfortable implications for OpenAI and Anthropic as they move toward IPOs. Their revenues may continue to grow quickly, but pricing power will face pressure from below. If open-weights models are good enough for a larger share of routine inference, enterprises will become more selective about when they pay premium API prices. They will still pay for frontier reasoning, managed compliance, uptime, enterprise support, convenience, and strong guardrails. But they will be less willing to send every summarization, extraction, routing, tagging, retrieval, and support workflow to the most expensive model. Revenue can grow while the price umbrella weakens.

The biggest uncertainty is supply. Open weights are not a guaranteed public good. They are a business decision, and business decisions can be reversed. OpenAI demonstrated that years ago. Meta now appears less committed to Llama as an open ecosystem than many expected. At the same time, the open-weights landscape has become more concentrated among Chinese labs, and even that supply is narrowing as some providers move toward closed or more restricted licensing under revenue pressure. This is the part of the story that deserves more attention. Enterprises should absolutely take open weights seriously, but they should not assume the ecosystem will remain abundant, permissive, and stable. The winning teams will be the ones that can test, route, govern, and replace models without rebuilding their AI stack every time the market shifts.

Tokenomics: AI’s New Design Constraint

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The Gap Between the Press Release and the Power Grid

Back in February, I wrote about what I called the “Data Center Rebellion,” the growing local resistance to the physical infrastructure behind AI. Since then, I have been asking tech people around the Bay Area how closely they are following the backlash. The answer is usually: they know it exists, but not much more than that. There is still a quiet assumption that most of these announced campuses will get built, plugged in, and brought online more or less on schedule. I am much less sure. What looked like a scattered set of zoning fights has hardened into something more organized, more politically potent, and more consequential for anyone trying to think clearly about AI infrastructure timelines. The opposition has gone from a speed bump to a genuine constraint.

The striking part is how broad the opposition has become. Polling suggests that resistance to local AI data centers is now a mainstream position, not a fringe one. And the “AI” label matters. Data centers have become a visible target for wider concerns about corporate power, electricity costs, water use, job displacement, surveillance, and who actually benefits from the buildout. The politics have also gone cross-ideological in ways that make this harder to dismiss. Environmental justice advocates, rural conservatives worried about local control, and labor groups anxious about automation are all finding common cause at the zoning board.

The Local Backlash Gets Smarter

The objections are practical and increasingly specific. Communities are worried about water in dry regions, electricity demand on strained grids, air pollution from backup power, the constant hum of cooling systems, farmland conversion, tax breaks, and the small number of permanent jobs these projects often create. The industry tends to lead with billion-dollar investment figures. Residents tend to ask a simpler question: what do we give up, and what do we actually get?

The tactics have matured too. This is no longer just online frustration or a few angry public meetings. Residents are using moratoriums, zoning challenges, lawsuits, ballot measures, protests, water-rights filings, and elections. What makes the backlash more durable is the trust problem. Shell companies, project code names, NDAs, fast-tracked approvals, and vague end-user disclosures make communities feel boxed out. Once that trust is gone, even reasonable technical claims start to sound like sales material.

Microsoft’s recent pledge to stop requesting NDAs is a useful illustration here. It’s notable precisely because it signals how widespread the practice has become. When a company feels compelled to make that kind of pledge, it’s an admission that the old playbook has become a liability.

Announced Capacity Is Not Real Capacity

Local opposition gets much of the attention, but it is only one constraint. Even if a project clears the political process, it still has to get power, transformers, electrical equipment, GPUs, memory, networking gear, cooling systems, utility approvals, and enough skilled construction capacity. In many markets, the bottleneck has shifted from “can you get the chips?” to “can you get the megawatts?” A site can have land, permits, and a glossy announcement and still sit idle because the electrical infrastructure is not ready.

That’s why the gap between announced capacity and capacity under construction matters so much. Of the roughly 12 GW of U.S. data center capacity announced for 2026, only about 5 GW is under active construction. That ratio gets worse, not better, for later years. The industry’s pipeline looks enormous in press releases and investor decks, but only a fraction appears to be moving toward actual completion on the promised timeline. The word “capacity” can mean too many things: land under option, a permitted site, a building shell, reserved power, an energized hall, installed racks, or revenue-generating compute. Those are not minor distinctions. They are the difference between a story the market wants to hear and an asset that can actually serve AI workloads.

The Trust Deficit Becomes an Execution Risk

The industry is responding, but mostly at the edges. Some developers are revising site plans, changing cooling designs, offering community benefits, making renewable-energy commitments, or becoming more selective about where they build. But they do not fully answer the harder questions: who pays for grid upgrades, who gets the water, who absorbs the noise and pollution, and who has the right to say no?

What concerns me is the financial exposure accumulating underneath all of this. More and more of this buildout is being funded through debt, long-term lease obligations, and capacity commitments made against a pipeline that is, in many cases, more announced than actually under construction. The hard question is whether the math works even if the projects do get built. Hyperscalers are spending as if AI infrastructure will unlock a very large new revenue pool. Maybe it will. But if capital spending keeps rising faster than revenue, the industry may discover that “demand” and “attractive return” are not the same thing. Either AI generates much more revenue than analysts currently expect, or some planned spending gets pushed out, scaled back, or canceled. That second outcome might not look like a crash. It could look like delayed campuses, slower GPU orders, tougher financing terms, and more “rephasing” language on earnings calls.

This is why I would not treat local opposition as a side story. The compute demand behind AI is not going away. That does not mean every project deserves a rubber stamp. It means the industry has to get much better at earning trust and building capacity that communities, utilities, and investors can actually live with. If AI infrastructure spending is helping support the broader economy, then a serious pause becomes a macro risk, not just an AI story. A slowdown isn't even the worst version of this. It is an AI economy where compute becomes scarce, expensive, and concentrated in the hands of the few companies and customers that can afford it. That would be a bad outcome for everyone who wants AI to become broadly useful, not just broadly hyped.

• The MANIAC. I know this is a 2023 book, but it feels even more worth reading now. As AI reshapes computing, research, and mathematics, this portrait of John von Neumann made me wonder what one of history’s great mathematical minds would make of the machines we’ve built. This is historical & biographical fiction at its best 💯

• Steve Jobs in Exile: The Untold Story of NeXT. I had a couple of professor friends who were devoted NeXT users, and this helped me understand why that little black cube inspired such loyalty. This is a sharp, readable look at Jobs’ wilderness years, and how what looked like a detour ended up shaping the Mac, the iPhone, and the tools we use every day.

• Inside the Box: How Constraints Make Us Better. I liked this book because its core idea feels especially relevant to AI right now. DeepSeek and other Chinese model builders are a good reminder that constraints do not always slow innovation down, sometimes they force teams to get sharper, scrappier, and more creative.

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

Your Enterprise Data Deserves Better Than a Chatbot

Large language models and their multimodal variants remain the foundation models most people encounter first. That makes sense. Text, images, audio, and video cover a huge range of knowledge-work tasks, and today’s chatbots are far more capable than the text-only systems many people first tried. But enterprise AI does not run on chat alone. It runs on tables, time series, transactions, telemetry, product catalogs, customer histories, service graphs, and messy operational data that rarely fits neatly into a prompt. Using current coding agents for data science makes this gap concrete. Generating Python and SQL is easy for an agent or an LLM, but data science requires a uniquely human skepticism to contextualize messy data and recognize when a result is simply too good to be true. We may finally be moving past the TINA phase of foundation models for enterprise AI, where the answer to every problem has been “just use an LLM.” A new wave of frontier models look more specialized and useful for the prediction and decision problems that actually run businesses.

Structured and Semi-structured Data Get Their Foundation Model Moment

Kumo’s foundation mode is aimed at one of the most valuable categories of enterprise data: structured relational data. Think customer records, orders, transactions, risk signals, and event histories spread across warehouses and lakehouses. The argument is straightforward: businesses still rely on slow, hand-built ML pipelines, while LLMs lose too much structure when tables are flattened into text. AutoML tried to automate this work, but mostly by tuning the old workflow of joins, features, and model selection. Kumo’s relational foundation model takes a different route: it treats a database as a graph, where rows and tables become connected entities. Instead of manually building features, the model attends over raw relational context and generates predictions such as churn risk, recommendations, fraud likelihood, or customer lifetime value. The appeal is workflow compression: fewer bespoke pipelines, faster iteration, and a prediction layer that agents or applications can call on demand.

The newer KumoRFM-2 release sharpens that pitch. It is described as a pre-trained model that can make predictions directly over multi-table databases using only a small number of labeled examples at query time. In other words, teams can ask predictive questions across connected tables without first flattening the data, building features, training a task-specific model, and maintaining a separate production pipeline. The reported benchmark results are notable because KumoRFM-2 claims to beat both supervised baselines and other foundation-model approaches on relational tasks while using a tiny fraction of the available labels.

That said, I would not treat this class of foundation models as a blanket replacement for every predictive system. For lower-stakes routing, forecasts, personalization, fraud triage, and operational scoring, the value could be immediate. For quantitative finance, regulated credit decisions, medical risk scoring, or underwriting, I would expect a more cautious path: careful validation, calibration checks, monitoring, challenger models, explainability review, and human governance before deploying to production.

Kumo isn’t the only active effort here. Prior Labs is pursuing foundation models for tabular data with TabPFN, a system aimed at row-and-column prediction problems such as churn, fraud, pricing, demand forecasting, credit scoring, predictive maintenance, and clinical risk. Its pitch is similar in spirit: reduce the amount of preprocessing, feature engineering, tuning, and model selection needed before teams get useful predictions. This momentum extends to temporal data, where an expanding roster of time-series foundation models can now generate reliable forecasts without prior, domain-specific fine-tuning. The important lesson is that structured enterprise data is becoming a first-class target for foundation-model development, with architectures that target tabular, relational, and temporal data.

Datadog is moving in a related direction, though it uses different language. At the AI Agent Conference, Ameet Talwalker described work on what Datadog calls a “world model” for observability. I think it belongs in this discussion because the inputs are largely structured and semi-structured operational data: metrics, logs, traces, service topology, code, events, alerts, and incident history. The goal appears to be a foundation model that learns how production software systems behave over time, not just a dashboard that summarizes what already happened.

The Toto 2.0 release strengthens that story. Toto began as a time-series foundation model for observability data, and the new version turns it into a family of open-weights models that scale from 4M to 2.5B parameters. Datadog’s results suggest that larger Toto models keep getting better, run much faster than the first generation, and generalize beyond observability despite being trained largely on observability and synthetic data. For enterprise teams, the practical implication is that telemetry may become a richer prediction layer for incident detection, root-cause analysis, simulation, and agentic remediation. The world model effort is the next step in that direction, moving beyond forecasting individual streams toward a learned model of how distributed systems fail, recover, and respond to change.

AI Moves Closer to the Point of Work

The same push toward specialization applies to how models interact with people, not just what they predict. Thinking Machines is training what it calls an “interaction model” for continuous, two-way exchange across audio, video, and text, rather than the familiar turn-taking pattern where a user speaks, waits, and receives a finished response. The key design choice is that the model works in real time, listening, responding, and tracking visual cues while deeper reasoning and tool use happen in the background. The enterprise relevance is direct: customer support, field service, sales coaching, clinical workflows, industrial operations, and design reviews all involve interruption, demonstration, and real-time correction. These are not clean prompt-and-response tasks. In many settings, the best interface is less like filing a ticket and more like working alongside a capable colleague. This is still a research preview with real constraints around connectivity and session length, but the direction is one that product and platform teams should be tracking.

There is also a related wave of specialized interface models that expand where AI can be embedded in workflows. Google DeepMind’s AI-enabled pointer imagines assistance that follows users across applications, understands what is on screen, and accepts natural instructions like “fix this” or “move that” without requiring a carefully written prompt. OpenAI’s real-time voice models point in a similar direction, with separate models for live reasoning, translation, and streaming transcription. The common thread is that these are less about building a general chatbot and more about making AI useful at the point of work. Put those alongside the structured data and observability models covered earlier and a clearer picture emerges: enterprise AI is developing a stack of specialized models, from prediction engines on relational and telemetry data to real-time interaction layers, all coordinated around the workflows where value is actually created.

Foundation Models Start to Specialize

World models is an emerging category I have not treated fully here. There is a lot happening, and some of it is genuinely interesting. But the world-model work I know best is not yet centered on the enterprise workflows I spend my time thinking about. My recent conversations with the founders of Rhoda AI and Odyssey made that clear. Rhoda is applying video-native foundation models to robotics tasks such as decanting, return processing, and container breakdown. Odyssey is building interactive world simulations, with early relevance for gaming, robotics, media, and other visual environments. These are important directions, but they sit closer to physical systems and simulated worlds than to the messy operational data, prediction problems, and knowledge-work interfaces that dominate most enterprise AI roadmaps.

The bigger takeaway is that foundation models are starting to specialize in useful ways. LLMs and multimodal chatbots will remain central, but they will not carry the enterprise AI stack by themselves. Enterprise AI will likely depend on a portfolio of more targeted models: relational models for structured data, time-series models for forecasting, observability models for production systems, interaction models for real-time work, and eventually world models where simulation and physical reasoning matter. The better end state is not one giant model that handles everything, but a routing layer that reads the task and directs it to the right model for the job.

When Agent Teams Reach for rote

Explore rote

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

Beyond the Demo: What Real AI Agents Actually Do at Work

I am always on the lookout for new AI agents and applications that operate outside the coding world. By agent, I mean a system that can take a goal, use tools, keep context, and work through several steps rather than simply answer a prompt. Looking through my notes from the recent AI Agent Conference, I put together a few standout examples drawn from conversations with the people who built them and friends at the conference. What stands out is not that these systems are magical. It is that they are showing up in ordinary business workflows where speed, judgment, and access to the right data matter.

When Marketplaces Start Doing the Work

Upwork’s Uma Recruiter starts from a familiar problem: hiring is not just search. A client may write an incomplete job post, miss important constraints, or fail to separate required skills from nice-to-have ones. Uma Recruiter turns that messy input into a structured hiring task, then searches the talent marketplace and evaluates candidates across signals like past work, portfolio depth, availability, prior client relationships, and Job Success Score. It then invites promising candidates and ranks incoming proposals. Upwork is treating a job post less like a one-time query and more like the start of a multi-step recruiting process. Early results suggest this is not just a demo: Upwork says Uma Recruiter can produce shortlists within six hours, initial testing showed a 30 percent increase in hires using the shortlist, time to hire fell 11 percent, and jobs filled within seven days rose 10 percent between November 2025 and March 2026.

DoorDash’s merchant tools are less like a single recruiter-style agent and more like a bundle of AI-enabled workflows placed directly into merchant operations. The core idea is to remove setup and growth tasks that independent restaurants often lack the time or staff to handle. Its AI-powered onboarding pulls information from a merchant’s existing web presence, including photos, hours, and menu items, so a merchant can review and edit rather than start from scratch. DoorDash says this helps merchants launch more than 35 percent faster. The suite also includes AI photo tools that retouch or replate food images while preserving the underlying dish, AI-generated branded websites for direct ordering, and AI-assisted marketing campaigns for email content and scheduling. Millions of photos have been enhanced, AI-powered websites are seeing nearly 10 percent average order conversion, and merchants report meaningfully reduced effort across onboarding and marketing.

The common thread is that both companies are using AI to make their platforms easier to use, not to replace the marketplace itself. Uma Recruiter is more explicitly agentic: it has a reasoning core, specialized tools, memory, and an iterative plan-act-assess loop that runs until it has a strong shortlist. DoorDash is more embedded and task-specific, appearing as product features that reduce merchant friction at known points in the lifecycle. For builders, the distinction matters. Upwork is automating a judgment-heavy workflow where the system must reason across candidates and outcomes. DoorDash is automating setup, content, and marketing jobs where usability, guardrails, and tight integration into the merchant portal may matter more than a visibly autonomous agent.

Two Paths to the Enterprise Agent

Meta’s AI Second Brain addresses a problem most knowledge workers recognize immediately: the context needed to do your job is scattered across documents, meetings, tasks, code reviews, and internal discussions. Rather than starting each session cold, the system gives an AI agent a persistent workspace organized around the PARA method, a lightweight structure for Projects, Areas, Resources, and Archives that tells the agent what you are actively working on, what to load on demand, and where to route new information like meeting notes. The agent connects to internal tools through authenticated MCP servers, which give it scoped, permissioned access to internal systems, and command-line interfaces. The adoption numbers are striking: more than 63,000 installs in roughly three months, around 10,000 daily active users, and thousands of user-created skills written in plain markdown. That kind of internal traction usually means the tool solved a real problem.

EY’s agentic AI effort targets a very different kind of knowledge work: audit and assurance. The firm is embedding a multi-agent framework directly into EY Canvas, its global assurance platform built on Microsoft Azure, Microsoft Foundry, and Microsoft Fabric. The system is designed to help audit teams orchestrate complex tasks, surface updated accounting and audit guidance, sharpen risk assessments, and reduce administrative overhead, while keeping human judgment explicitly in the loop. The scale is institutional rather than viral: 130,000 assurance professionals, 160,000 audit engagements, more than 150 countries, and a roadmap to support end-to-end audit activity by 2028.

The shared lesson is that internal agents need far more than a capable model underneath them. They need access control, structured context, workflow integration, and a clear boundary between AI assistance and human decision-making. Where the two cases diverge is in philosophy. Meta’s system grew from the bottom up: users write their own skills, teams extend workflows, and adoption spread because the entry cost was low and the system was composable. EY’s deployment is top-down by design, embedded inside a regulated professional platform where governance, quality controls, and training matter as much as productivity gains. Some agents spread because people can adapt them. Others earn trust precisely because they cannot be adapted freely.

When the Data Is the Moat

RealAI is an AI real estate analyst for investors, multifamily professionals, agents, homebuyers, and renters. The pitch is that property and market analysis that once required specialized teams or expensive institutional tools that can now be done conversationally. RealAI can compare markets, evaluate properties, model returns, and surface data on rents, sales histories, demographics, household financials, migration trends, and market dynamics across U.S. residential properties. Fundrise claims underwriting that previously took days can now be completed in seconds. The owner-developer of New York City’s World Trade Center, said complex analyses that once took days can now be completed in minutes. RealAI is priced accessibly for individual investors and smaller firms that have historically been priced out of this kind of intelligence.

The most important part of RealAI may not be the chat interface or the agent harness, the layer that routes tasks to the right tools and data sources. It is the data underneath it. Fundrise describes a system trained on tens of thousands of hours of internal team experience and a database of roughly 3.5 trillion data points covering every residential property in the country, drawn from public records and private databases and updated in real time. The interface can be redesigned and the orchestration layer can be swapped out. But assembling, cleaning, connecting, and continuously refreshing domain-specific data at that scale is the genuinely hard part. In many applied agent systems, durable advantage lives below the model, in the data.

What Makes Agents Stick

These cases make me less interested in agents as a category and more interested in the conditions that make them useful. The pattern is not simply “give a model tools.” The better examples sit inside real work loops, draw on domain-specific data, preserve human control where judgment matters, and have enough memory to carry context across steps without dumping everything into every session. They also need less glamorous machinery: access control, retries when tools fail, logging that explains why the agent acted, evaluation tied to business outcomes, and cost discipline so every step does not require the most expensive model. That is where many agent projects will succeed or fail, not in the demo.

The workforce question is also sitting just below the surface of most of these deployments, even when it goes unspoken. Fundrise’s Ben Miller is unusually blunt about the labor consequences. He says AI will cause job losses across commercial real estate, and while Fundrise has not laid people off, the company has slowed hiring. That is a more candid framing than most companies are willing to offer publicly, and it is worth taking seriously. The systems described here are not replacing human judgment in the high-stakes moments, but they are compressing a significant amount of the work that surrounds those moments. For anyone building or buying agents, the value is real, but so are the organizational consequences.

When AI Found the Counterexample

Vatican to AI Leaders: Efficiency Is Not Enough

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

Integration Is the New Moat: Moving Beyond the LLM

The AI Agent Conference in New York was one of the better events I’ve attended to get a read on what’s actually happening with enterprise AI. The formal sessions were great, but the hallway conversations was where I got the inside scoop. The consistent message: deploying AI agents is much harder than most organizations expect, and the reasons are rarely the ones they anticipate. What follows is my attempt to distill what I heard into a practical view of why enterprise agents are so hard to deploy.

The first barrier is integration. In one enterprise after another, agents run into older CRMs, finance systems, document stores, and homegrown tools that were never designed for autonomous software. What looks like a wiring problem usually isn’t. A logistics company built a capable agent that fell apart the moment it had to touch their order management system, a decade-old platform never designed to be queried by software making autonomous decisions. The agent wasn’t broken. The process it was dropped into was. The worst failures are often the ones that stay hidden. A financial services firm ran an agent successfully in its test environment for months, only to discover during a quarterly audit that production CRM records had silently stopped updating. No error, no alert, just bad data accumulating for three months. Teams that treat integration as a technical handoff rather than a workflow redesign problem consistently get stuck at the same wall.

The data situation compounds this at every layer. Enterprise knowledge doesn’t live in clean, queryable databases. It lives in Confluence pages nobody maintains, Slack threads from two years ago, and the heads of three people who’ve been at the company long before the current CTO arrived. One study found that more than a quarter of agent deployment failures trace directly to critical knowledge that was never captured anywhere a system could reach. When agents fail on company-specific terminology, like non-standard product codes or internal procurement shorthand, the instinct is to upgrade to a more powerful model. That instinct is almost always wrong. The fix is domain-specific examples and better knowledge capture, not a bigger model. And underneath all of it, security cannot be an afterthought. Agents need governed, scoped access to data, with proper permissions and audit trails built in from the start. Without that foundation, even a well-integrated, well-trained agent is a liability waiting to surface.

Agents Don’t Fix Broken Processes, They Find Them

But even when integration is solid and data is in order, most deployments hit a third wall that almost nobody budgets for: the organization itself. Agents do not arrive as neutral software upgrades. They ask people to change how work is routed, approved, measured, and owned. In a hospital system, that might mean deciding whether an agent can prepare a prior authorization packet before a clinician reviews it. In an industrial manufacturer, it might mean exposing the informal workaround a plant manager has used for years because the official process is too slow. In an insurance operation, it might mean discovering that no one can explain who is accountable when an agent recommends a coverage decision that later gets challenged. These are not edge cases. They are the work.

This is why early agent projects often fail in a way that is politically expensive. A weak first deployment does not just miss a KPI. It convinces managers, operators, and risk teams that the whole category is immature or unsafe. The harder second attempt, the one that would involve process audits, clearer ownership, better evaluations, and serious change management, may never get funded. In practice, deploying agents means changing the organization while the organization is still running. That is slower and messier than a demo, but it is also where the real implementation work begins.

Compounding all of this is a talent problem with no clean solution. Deploying agents at scale requires people who understand process design, LLM behavior, systems integration, and organizational change, all at once. That combination is genuinely rare, and companies that hire for one or two of those skills and assume the rest will follow are setting themselves up for the same failure pattern, just with different symptoms.

Agents Are Implemented, Not Installed

The real implementation work isn’t getting an agent to run correctly in isolation. It’s getting the agent to run correctly inside a live organization, where the work is distributed across roles, the accountability is murky, and the processes were designed around human judgment calls that nobody ever wrote down. What looks like an AI project is usually a process redesign project with an AI component attached. The companies that figure this out early tend to scope their first deployments around a specific, broken workflow rather than a whole function or department. Not “automate the sales team,” but “automate the part of lead qualification that requires pulling the same three fields from two systems and writing the same email 200 times a week.” That narrower target is less exciting to demo but far more likely to survive contact with the organization. Enterprise agents are not installed. They are stood up, governed, monitored, and gradually expanded.

The implementation gap has also created a staffing model that most organizations haven’t fully absorbed yet. The most effective deployments involve a dedicated operational owner for each agent in production, someone who sits at the intersection of the business workflow and the technical system, and who can tell the difference between an agent that’s working and an agent that’s producing plausible-looking output that nobody has actually verified. Some vendors have formalized this with embedded specialists, technical product managers or forward-deployed engineers whose job is to live inside the customer’s workflow until the deployment actually holds. Without that kind of ownership, agents in production become side projects maintained by whoever built the prototype, and the research bears this out: organizations that skip dedicated ownership are dramatically more likely to face failures that require rolling the whole thing back. The talent profile this requires doesn’t map cleanly onto any existing job title, which is part of why so many companies are either building it from scratch or outsourcing it to implementation specialists who’ve learned these lessons on someone else’s dime.

Integration Is the New Moat

The next durable advantage in enterprise agents will not come from picking a cleverer model. It will come from making agents usable inside messy, specific, high-stakes workflows. A legal team does not need a model that can sound like general counsel in the abstract. It needs a system that can find the right contract, apply the company’s negotiation playbook, respect approval thresholds, and leave a clean audit trail. A customer support operation does not gain much by giving every human agent a better copilot. It gains real leverage by redesigning the service so routine cases resolve end to end, with people handling the work that requires judgment, empathy, or escalation.

A manufacturer running fragmented ERP, procurement, and plant systems will not close the competitive gap by waiting for larger models. It will close the gap by modernizing the connective tissue of the business. The raw intelligence of foundation models is becoming a commodity faster than most people expected. What remains scarce is the integration depth, the governed data access, the workflow redesign, and the operational ownership that make agents actually hold in production.

That gap is also a market. Vendors, integrators, and internal transformation teams that can do the unglamorous work, connecting legacy systems, capturing institutional knowledge, building evaluation frameworks, managing the organizational change, are sitting in front of a real and durable opportunity. The distance between what foundation models can theoretically do and what enterprises can actually deploy is not closing on its own. The companies that treat integration, governance, and workflow redesign as the product rather than the plumbing will be the ones that turn agents from demos into operating leverage.

The Three Pillars Behind DeepSeek’s $51.5B Premium

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The End of the AI Experiment: Surviving the CFO’s New ROI Demands

Why This Has Become an Executive Issue

Why is AI spend no longer just an IT budget problem? AI has crossed a threshold where aggregate spend across every department requires capital allocation discipline, not just software procurement review. Every function now has a case for AI investment, and someone has to decide which requests deserve ongoing funding. That decision has landed with the CFO, which means technology leaders who frame AI proposals as feature requests will lose funding to peers who can demonstrate measurable business outcomes.

What do “tokenomics” and “tokenmaxxing” actually mean in practice? Tokenomics is simply the practical economics of AI usage: how prompts, automated workflows, and background agents translate into real spending, and whether that spending is producing value. Tokenmaxxing is the emerging habit of pushing more work through AI because tokens feel cheap, or because high-consumption workflows appear more productive. The instinct can be rational, but it creates a governance problem because organizations need a way to distinguish productive consumption from wasteful consumption, and most have not built that capability yet.

Why are AI bills climbing even though token prices keep falling? Lower unit prices are encouraging more consumption, not less. As tokens get cheaper, teams build more ambitious systems: more automated, more context-heavy, always-on agents running continuously in the background. The marginal cost of any single query feels negligible, so consumption expands to fill whatever budget exists. Organizations focused purely on negotiating lower unit prices while ignoring how their systems are designed will find their total bills climbing regardless.

Why is CFO scrutiny intensifying right now? The broad experimentation phase is ending. Many organizations have deployed AI in some form, but far fewer believe those deployments have produced tangible value. Once that gap becomes visible, finance teams stop treating AI as a learning exercise and start demanding evidence for continued investment. The funding logic shifts from supporting a large portfolio of loosely defined experiments to concentrating resources on fewer workflows with a clear payback case.

What Leaders Should Actually Govern

What is the right unit of control: seats, teams, vendors, or workflows? The most useful unit of governance is the individual application or workflow, not the software seat or department budget. AI costs are generated by usage patterns, not by who holds a license. A single automated workflow can quietly consume more tokens than dozens of human users combined. Budgeting at the workflow level makes it possible to see which use cases are scaling, which are overrunning, and which should be redesigned or shut down.

When do spending caps help, and when do they backfire? Caps help when they prevent undisciplined growth in low-value usage, particularly when nobody can explain where the spending is coming from. They backfire when they suppress the most productive work. If your highest-consuming teams are also your highest-performing ones, a blanket ceiling is a tax on performance dressed up as financial discipline. The right sequence is to instrument outcomes first, then decide where controls belong.

What should leaders actually ask when a vendor proposes outcome-based pricing? Outcome-based pricing sounds appealing because it appears to align vendor incentives with business results. That alignment is not automatic. It depends entirely on how the outcome is defined, how success is verified, and what happens when the system produces something that technically triggers a charge but does not create real value. Leaders should ask who defines what counts as a valid outcome, how disputes are handled, and whether the vendor has any incentive to maximize billable events in ways that diverge from the customer’s actual objective.

Why do different AI pricing models need different governance approaches? Not all AI spend behaves the same way. Subscription pricing buys predictability but can conceal waste inside a flat fee. Usage-based pricing makes activity visible but creates volatile invoices. Outcome-based pricing sounds more business-friendly, but it can obscure the operational work required to verify whether the billed result was correct, complete, and valuable. The shift toward seats-plus-consumption adds another complication: buyers may renew a familiar per-seat contract while also taking on usage charges, credits, agent actions, or outcome fees that behave very differently. Leaders need governance that matches how value is claimed, how cost is incurred, and how performance can fail. Otherwise, they risk optimizing the old pricing model while their real exposure has already moved somewhere else.

Visibility: The Prerequisite for Everything Else

What is the single most important governance gap right now? Attribution. Most organizations cannot answer the basic question of which team, workflow, or agent is consuming how many tokens, and what business outcome that consumption supports. Without that visibility, every other governance mechanism, whether caps, chargebacks, or ROI thresholds, operates on incomplete information. Solving attribution is the prerequisite for everything else.

What does good visibility infrastructure actually look like? It means purpose-built dashboards that surface per-workflow and per-agent consumption in near real time, not month-end invoices that arrive with no ability to trace costs back to specific decisions or teams. Salesforce expanded its internal Engineering 360 dashboards to track AI usage at the workflow and team level, showing how companies often need custom visibility tools when standard reporting does not give leaders a clear view of token consumption, agent activity, and adoption patterns. This is an area where early investment in custom observability pays off rather than waiting for the vendor ecosystem to catch up.

How does token consumption become a productivity signal rather than just a cost metric? High token consumption and high-quality output often correlate. Before setting any controls, connect token spend to actual business outcomes: deals closed, issues resolved, code shipped, churn prevented. Once you have that picture, invest more in the high-correlation workflows and scrutinize the rest. Organizations that skip this step and go straight to spending ceilings risk penalizing their most productive teams first.

Practical Governance Mechanisms That Work

What is the most actionable governance step we can take right now? Set per-application token budgets with automated alerting thresholds, and require cost-impact assessments for any new AI feature before it ships. Build that review into sprint planning rather than treating it as a finance team afterthought. This embeds financial discipline into the development process rather than bolting it on after costs have already run up.

What are FinOps practices and why do they matter for AI? FinOps is the discipline of bringing financial accountability to technology spend through collaboration between engineering, finance, and business teams. Applied to AI, it means forecasting token demand before projects launch, setting ROI approval gates for competing use cases, and implementing chargebacks so business units bear the actual cost of their own consumption. The chargeback mechanism in particular creates real incentives for teams to ask whether their usage is justified.

How should infrastructure choices factor into AI cost governance? Stop treating all AI workloads as equivalent from a cost perspective. Public cloud is the right choice for experimentation and burst capacity where flexibility justifies the premium. Predictable, high-volume inference workloads are better suited to private or on-premises infrastructure where fixed costs outperform consumption pricing over time. Defaulting everything to public cloud absorbs a premium that compounds significantly as workloads scale.

Procurement and Organizational Risk

Our vendor contracts are still per-seat. Is that a problem? Yes. Per-seat pricing no longer maps cleanly to how AI systems generate costs. In many AI-heavy products, the seat is becoming a wrapper around a base level of included usage rather than a reliable proxy for total cost. Every prompt, automated workflow, and background agent can burn tokens regardless of how many people are licensed, creating invoice volatility that per-seat budgeting cannot predict. Push for hybrid models that combine a predictable baseline fee with usage-based pricing above agreed thresholds, with explicit price caps, volume commitments, reporting rights, and overage terms built in.

What changes when a seat becomes a consumption bundle? The license still matters because it controls access, but it no longer tells you enough about cost. Two teams with the same number of seats can generate very different bills if one uses AI for occasional drafting and the other runs context-heavy agents across customer support, software development, or security workflows. Procurement teams therefore need to negotiate included usage, overage rates, usage reporting, and contractual limits on unexpected consumption. The buying question shifts from “how many people need access?” to “how much machine work are we authorizing?”

What is the governance maturity gap for agentic AI? Agentic AI refers to systems that take sequences of actions autonomously rather than responding to a single prompt. That matters economically because an agent is not naturally a seat-based user. It performs tasks, calls tools, consumes tokens, and may keep working after the human has stepped away. Research suggests only about one in five organizations planning to deploy agentic AI has a mature governance model in place. Without clear accountability structures and performance metrics, organizations accumulate what practitioners call “content debt,” meaning AI-generated outputs requiring human remediation that erode the ROI case for further investment. Building governance before you scale is significantly cheaper than retrofitting it after problems surface.

How should we frame AI cost governance to get board-level attention? Frame it as a competitive risk, not a budget management problem. Unmanaged AI consumption erodes margins in a way that compounds over time, and organizations that govern their AI economics well will have a structural cost advantage over those that do not. Tokens are becoming a real operational input, and treating them with the same rigor applied to energy procurement or capital expenditure is not optional for organizations that intend to scale AI seriously

🎗️Cerebras IPO🎗️

Cerebras is going public this week, a milestone for an AI infrastructure company I have followed since its early days. I first met CEO Andrew Feldman in early 2018, before Cerebras had released its first processors and when the company was still focused mainly on AI training. After its first-generation chip came out, one of the first talks the team gave was at a conference I co-chaired in 2019. What makes this IPO especially interesting now is Cerebras’s growing focus on inference, the work of running trained AI models to produce answers, code, images, or other outputs. That shift matters as more enterprises move AI into production and as reasoning models use more compute while generating responses, not just during training. For those of us who build, buy, or use AI applications, another strong, speed-focused alternative to Nvidia is welcome news.

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

Why Your AI Agents Fail in Production (And How to Actually Test Them)

In a previous post, I argued that deploying autonomous AI agents reliably is not primarily a model problem. It is an environment problem. The gap between a capable foundation model and a production-ready system is bridged by harness engineering: the discipline of building structured workflows, validation loops, and governance mechanisms around the model rather than inside it. The central argument was that organizations that treat the surrounding environment as the primary engineering target outperform those that chase better models, and that this principle applies across every domain where agents handle complex, consequential work.

That argument raises an immediate practical question: how do you actually know whether an agent is ready for that work? Most existing evaluations still measure narrow, low-friction tasks in controlled or synthetic environments. They can tell you whether a model produces a plausible answer or completes a neat subtask, but they reveal far less about whether an agent can stay coherent across a long workflow, adapt when something breaks, and finish a job that actually runs. Many benchmarks were simple enough that top models were already approaching perfect scores, leaving no meaningful signal about which systems could handle real work and which could not.

What production usually demands is sustained execution under friction: long chains of interdependent actions, genuine error recovery, and deep domain knowledge applied to messy, open-ended objectives. That is a fundamentally different test than anything most benchmarks were designed to measure. The commercial stakes behind closing that gap are no longer abstract. Terminal-based coding agents alone are already generating billions in revenue, which means accurate measurement of what these systems can and cannot do in realistic conditions has moved from research interest to commercial necessity for anyone building, deploying, or investing in AI agent products.

Measuring the Agent, Not the Demo

Some of the most capable autonomous agents in production today are still concentrated in coding and software engineering. That makes sense. The terminal is one of the few environments where success criteria are clear and feedback arrives immediately. An agent cannot hide behind a fluent answer when a build fails, a dependency breaks, or a command returns the wrong output. It has to keep working until the job is done.

Terminal Bench was built around that reality. It places agents inside real terminal environments loaded with the files, packages, and system configurations needed for the task. Each problem includes an instruction, a verification script, and a reference solution. What gets measured is not whether the agent followed a preferred sequence of steps, but whether it reached a machine-checkable result. There is no partial credit for looking competent. The output either works or it does not.

The significance is not just that Terminal Bench is harder. It is harder in ways that matter. Previous benchmarks often measured narrow command-line skills, relied on synthetic environments, or used tasks so short that they revealed little about sustained execution. Terminal Bench instead asks whether an agent can manage long sequences of dependent actions, recover from real error messages, and apply domain knowledge to open-ended work. Its rigor also comes from the curation. Every task in Terminal Bench is manually reviewed to reduce broken tests, underspecified instructions, and loopholes that let agents game the evaluation. The early results show why that level of manual verification matters. Frontier agents still fail more than a third of the tasks, and smaller models perform much worse. For anyone building, deploying, or investing in agents, that makes Terminal Bench less a leaderboard curiosity than a practical instrument for separating systems that look capable from systems that can actually finish difficult work.

The Emerging Infrastructure for Real Agent Evaluation

Terminal Bench has not developed in isolation. A small but important set of related efforts is now building on the same premise that agent evaluation should look more like real technical work and less like a polished demo. LongCLI-Bench pushes this further by focusing on longer command line tasks and by adding step-level scoring, so an agent is penalized not only for failing to finish the job but also for breaking something that previously worked. That is a meaningful advance for anyone building production agents, because regression is often the real failure mode. DevOps-Gym pushes the boundary further into real-world software operations, evaluating agents on their ability to configure builds, monitor systems, and resolve live issues instead of just completing isolated terminal prompts.

The ecosystem is also expanding into the infrastructure needed to train and compare terminal agents at scale. TermiGen addresses one of the clearest bottlenecks exposed by Terminal Bench, namely the cost of hand-building realistic environments and trajectories for training and evaluation. Terminus and Terminus 2 provide reference implementations for how a terminal agent can interact with a live shell over many steps, which makes them useful both as engineering baselines and as cleaner testbeds for comparing models. And the appearance of fine-tuned terminal-focused systems such as Reptile, LiteCoder-Terminal, and TerminalAgent suggests that terminal competence is now being treated as a distinct capability worth training for directly. Taken together, these developments make Terminal Bench look less like a standalone benchmark and more like the anchor for a broader effort to measure and improve agents that have to do real work under real constraints.

What Comes Next, and What It Means Outside the Terminal

The near-term roadmap for Terminal Bench is really about keeping the benchmark informative. As agents improve, benchmarks only stay useful if they keep stretching the best systems, which means adding harder tasks, expanding domain coverage, and refreshing the suite before leaderboard movement stops meaning anything. Just as important, the Terminal Bench team is making an explicit argument that manual verification is not optional. Their experience showed that confirming task correctness, closing loopholes, and fully specifying success conditions takes substantial human effort, and that cost rises with task complexity.

The infrastructure supporting Terminal-Bench has become more valuable than the benchmark itself. Harbor serves as the expanded framework that allows developers to go beyond basic testing, giving them the tools to optimize AI prompts, run trial-and-error learning, and perform automated quality checks on their agents. That is a meaningful shift. Evaluation is no longer a report card at the end of a development cycle. It is moving into the development stack, not sitting outside it. The ecosystem growing around Terminal Bench is what that shift looks like in practice.

For companies building agents outside coding, this is probably the clearest near-term lesson. The winning approach is unlikely to be full autonomy across messy, high-stakes workflows. It is more likely to be structured human-agent collaboration inside tightly engineered environments. That fits the larger argument in my previous post. The real leverage comes from the surrounding system, not just the model. Terminal Bench sharpens that claim by showing that even in a domain where feedback is fast and success is machine-checkable, reliable autonomous performance remains limited. In domains where mistakes are subtler and more consequential, companies will need even more harness, more evaluation, and more deliberate handoffs between automated execution and human judgment.

Quantum Computing Supply Chains

• The Laws of Thought: The Quest for a Mathematical Theory of the Mind. AI is starting to shape the economy, the job market, and national security. That’s why I think more people should understand the concepts in this highly readable book.

• Mutiny: The Rise and Revolt of the College-Educated Working Class. The college grads making lattes and running Apple Store demos are already living the gap between what their degrees promised and what the economy delivers. With AI moving into knowledge work, that gap may widen for many more people.

• London Falling. One of my favorite writers delivers again here. I came away feeling like London is not just the setting but almost a character in its own right, with all its glamour, fraud, and seedy underbelly baked into the story.

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

What mathematicians figured out about AI that most enterprises haven't

Recent results suggest that research mathematics is no longer a purely speculative test case for AI. A growing set of examples shows AI contributing not just to short contest puzzles, but to open-ended mathematical work that requires literature search, cross-domain connection-making, revision, and verification. The important lesson for enterprise AI teams is not that AI has suddenly become a mathematician. It is that progress accelerates in settings where outputs can be checked, workflows are iterative, and human experts remain responsible for choosing the right problems. Mathematics makes these conditions unusually visible, but the broader pattern maps directly to enterprise AI systems built around retrieval, structured feedback, and human oversight.

Research mathematics might seem like the last domain to yield to AI, given its reputation for requiring deep intuition and creative leaps. Yet several structural features make it surprisingly well-suited for AI augmentation. Mathematical claims are either correct or incorrect, which means AI outputs can be verified with certainty, either by human experts or by formal proof systems. This eliminates the trust problem that plagues AI in domains where ground truth is subjective. Additionally, a large fraction of research work involves tasks that are tedious but not conceptually deep: writing experimental code, checking computations, finding citations, exploring minor cases, and surveying literature across subfields. AI handles these tasks well, freeing human researchers for higher-level reasoning.

The existence of formal proof languages and large mathematical libraries creates an infrastructure that is uniquely favorable for AI integration. Tools like Lean and Mathlib translate abstract mathematics into machine-readable, computationally certified code, providing both a training ground for AI systems and a verification layer for their outputs. This ecosystem enables a genuinely new workflow where AI proposes and humans verify, or where AI explores at scale and humans direct the search. The result is not replacement but restructuring: mathematics is becoming a hybrid process where large-scale exploration, formal verification, and human-guided insight combine into a new mode of discovery.

How AI Is Reshaping Mathematical Workflows

Research mathematicians currently deploy AI across a few workflows, starting as a disciplined assistant for work that is useful but easy to verify. They hand off tasks such as writing experimental code, checking large numbers of computational cases, and finding citations, but only when the result can be tested independently. That trust boundary matters. Researchers are not treating a language model as an oracle, but rather using it where mistakes are visible and fixable. A second pattern is broader literature scanning. Because mathematics is so specialized, important ideas are often buried in distant subfields or older papers. AI helps widen the search, systematically surfacing analogies and relevant results from outside a researcher’s immediate area. The system acts as a multiplier for breadth, while human experts provide the depth of insight needed to judge which connections are genuinely useful.

A more advanced set of workflows is now taking shape where verification is even stronger. Some researchers use systems that combine pattern-based AI with formal logic to get verified answers to specific research questions. The AI performs extended reasoning and translates the result into a formal proof language, ensuring the output is mathematically guaranteed. In parallel, other mathematicians are using AI to conduct large-scale experimental surveys of entire problem classes. The AI systematically maps the landscape, resolving routine cases automatically and flagging the smaller set of problems that still demand new conceptual approaches. The broader lesson is not that AI replaces expert reasoning. It is that AI becomes transformative when paired with structured feedback, clear verification, and a workflow that lets humans concentrate on the genuinely hard parts.

Possible Future Workflows for AI-Guided Mathematical Discovery

As these systems mature, research mathematics will likely illustrate a broader shift now visible in many knowledge-heavy fields. The mathematician of the future will spend less time carrying out long derivations by hand and more time deciding which problems deserve attention and where scarce computing resources should be focused. The transition mirrors the shift in software engineering from writing individual lines of code to designing system architectures. AI will handle the execution layer by searching for possible proof paths, scanning literature across distant subfields, and checking results in formal verification environments. The human role moves upward toward judgment, priority setting, and significance. For enterprise AI teams, this is a familiar pattern. As systems improve, the bottleneck shifts away from raw execution and toward problem selection, workflow design, and review.

A more ambitious trajectory sees AI moving from a disciplined assistant to an active research partner. In this model, the system proposes hypotheses, surfaces analogies, and explores many more directions than any one person could track alone. In specific settings, this could eventually extend to largely autonomous research loops where the AI identifies tractable open problems, tests candidate solutions, and drafts papers. Early versions of these autonomous agents already exist and have successfully resolved minor historical math puzzles. Yet the likely near-term outcome at the frontier of research is not full autonomy. It is a staged model in which AI expands the search space while humans retain responsibility for deciding what matters, which results are credible, and who bears accountability for the final product. That lesson should resonate well beyond mathematics. In enterprise environments, the most valuable AI systems will not be the ones that fully replace experts. They will be the ones that widen exploration, tighten verification, and make expert attention more selective and strategic.

Beyond Generation: What Math Reveals About Production AI

What mathematical AI makes especially clear is that hallucination is not mainly a prompting problem. It is an architectural problem, and it demands structural solutions. For high-stakes enterprise systems, prompt engineering and occasional human spot-checks are too weak to carry the load. The more durable pattern is to combine the breadth and fluency of generative models with deterministic checks: a code model paired with automated tests, a contract assistant constrained by a compliance engine, or an agent whose actions are filtered through policies, schemas, and hard business rules. Once those components are embedded in iterative loops in which the system generates, critiques, and revises, organizations can push AI further without simply scaling the risk. That is the broader lesson from mathematics. As generation gets cheaper and more abundant, the real bottleneck shifts to evaluation. Teams that build strong verification environments will be far better positioned than those that produce large volumes of plausible but weakly checked output.

That design choice also changes the role of the expert. When systems are built for verifiability from the start, the machine can take on more of the first-pass burden of checking, leaving humans to focus on higher-order judgment: deciding what matters, what is worth pursuing, and where ambiguity still requires experience and taste.

Mathematics offers an early preview of that shift. The strongest mathematicians, perhaps even future Fields Medalists, may be the ones who are best at using AI to explore more possibilities, test more ideas, and concentrate their own effort where originality matters most. The same logic applies across the enterprise. The most effective knowledge workers will not simply be those who use AI to move faster. They will be the ones who know how to direct it across a large search space, surround it with structural feedback, and intervene at the moments where human judgment creates the most leverage.

The AI Race Is No Longer Just About Benchmarks

Introducing rote™: Procedural Memory for AI Agents

In a previous piece, I argued that AI teams need operational memory, not just larger context windows or more elaborate prompts. Modiqo’s rote™ pushes that idea into a concrete system: agents should reason through genuinely new work once, then capture what worked as reusable procedural memory. That matters because many teams are now discovering the same failure mode in production agent systems: demos are easy, but reliable, repeatable workflows are hard. The challenge is no longer just connecting a model to tools. It is designing an environment where agents can remember successful work, reuse proven flows, and reduce the cost of rediscovering the same answer over and over. For teams trying to move from impressive prototypes to durable AI infrastructure, Modiqo is worth watching. Check out rote™.

Learn More

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The Missing Layer: Why Your AI Agent Fails — and What Actually Fixes It

As organizations move autonomous AI agents from experimental sandboxes into live production, a critical bottleneck has emerged. Foundation models are remarkably capable but structurally unsuited to complex, multi-step work on their own. They have no persistent memory, no built-in sense of what is allowed, and no reliable way to stay on track across a long workflow. Left to their own devices, foundation models hallucinate bad decisions, lose track of context mid-task, and generate cascading errors that are expensive to unwind.

Software engineering teams were the first to hit this wall at scale, and their response offers a practical blueprint for every domain now building AI-powered applications. Their conclusion was counterintuitive: scaling AI reliably is not primarily about making the underlying model smarter. It requires a completely different discipline focused on building a structured, automated environment around the model. That discipline is called harness engineering, and its principles extend well beyond writing software.

The Core Concept

Harness engineering treats the AI model as a fixed engine and builds the entire operational system around it: workflows, specifications, validation loops, context strategies, tool interfaces, and governance mechanisms. The model stays the same. Everything around it changes.

The distinction from adjacent approaches is fundamental, not incremental. Prompt engineering optimizes what you say to a model for a single interaction. Model fine-tuning adjusts the model’s internal weights to adapt it to a specific domain. Harness engineering does neither. It accepts the model as it is and focuses entirely on the environment the agent operates inside. Practitioners describe it as “meta engineering: building the factory rather than the product.”

The formal framing organizes a harness along three dimensions. Context covers the declarative and procedural knowledge that informs the agent. Constraint covers the rules governing agent output both before and after it is produced. Convergence is the iterative process by which constraints are evaluated, gaps identified, and rules refined until the harness reaches what practitioners call structural idempotence, the point at which re-applying the checks produces no further changes. The system has stabilized.

OpenAI’s Codex team put the shift plainly: a software engineering team’s primary job is no longer to write code, but to design environments, specify intent, and build feedback loops that allow agents to do reliable work. The mental model practitioners use involves three nested loops. The outer loop, at the project level, handles intent capture through specifications, architecture documents, knowledge bases, governance rules, and human oversight. The middle loop, at the task level, handles execution through the agent’s active work cycle. The inner loop, at the action level, handles verification through immediate feedback, automated tests, and automated rule checks that scan each output against a defined set of constraints and flag anything that violates them. This layered architecture originated in software development, but any team deploying autonomous AI agents to handle complex workflows faces the same underlying problem: a capable model is not the same as a reliable system.

The Anatomy of a Reliable Agent System

Translating the lessons of software harness engineering into broader business applications leads to a set of operational patterns. These practices group into four categories that shape how teams design, build, and govern autonomous agents in any high-stakes domain.

The Strategic Mindset Shift

The most fundamental adjustment for teams deploying AI agents is a complete inversion of their daily focus. Rather than optimizing the underlying model or manually reviewing every output, practitioners must shift their attention to architecting the environment where the agent operates. This means treating the model as a fixed engine and investing in the surrounding validation infrastructure, turning domain experts from manual reviewers into system designers. The evidence for this reframing is concrete: LangChain moved a coding agent from 30th to 5th place on an industry benchmark by changing only the harness, not the model. The same dynamic applies in any domain. A legal research agent will not become reliably accurate by switching to a more capable model if the validation layer cannot catch citation errors. When an agent produces a bad output, the first question should be “what is missing from the surrounding environment?” not “how do we change the model?”

The true return on investment for an agent system is not measured in tasks completed but in expert human attention hours saved. Every failure pattern encoded as an automated rule reduces future review burden, which means the harness is not a setup cost but a compounding asset that grows more valuable with each iteration. The primary deliverable for the domain expert becomes the testing suite and evaluation pipelines rather than the content the agent produces. A domain expert who insists on reviewing every output does not become a quality guarantor. They become a ceiling on what the system can ever achieve.

Architecture and Orchestration

Once the mindset shifts to environment design, the architecture of the system must enforce strict boundaries and predictable workflows. Rather than granting a single agent freeform autonomy to complete a complex task, robust systems rely on structured orchestration. A fixed control layer governs how the process moves from one defined step to the next, so the agent is never left to decide on its own what to do next or whether a step can be skipped. A clinical documentation agent should never decide on its own whether to file a record, request clarification, or escalate to a physician. A procurement agent should not unilaterally skip an approval step because the task looks routine. Structured orchestration makes agent behavior auditable, predictable, and recoverable regardless of domain.

Paired with this are two supporting elements. Teams must also build durable documents that live permanently inside the agent’s operating environment. These files encode the institutional knowledge the agent needs to behave consistently across every session: regulatory constraints, brand voice rules, escalation thresholds, and the rationale behind key decisions. Without them, agents operate from whatever context a user happens to provide, which produces inconsistent and unpredictable behavior. These anchors ensure consistent behavior regardless of how a session begins, rather than relying on ad hoc instructions that vary by user. Complex tasks should also be decomposed into specialized agent roles with explicit, structured handoffs between them.

A grant writing system might feature a research agent, a drafting agent, and a compliance review agent operating in sequence. Specialization narrows the blast radius of individual failures and makes each component easier to test and improve independently. Every connection to an external tool or data source must carry explicit permission limits enforced mechanically, because without those boundaries, agents can access sensitive data inappropriately or trigger irreversible operations in connected systems, and that risk scales directly with the number of agents running in parallel.

Validation, Feedback, and Escalation

A well-architected environment requires automated mechanisms to catch errors early and correct them cheaply. The strategic optimization target is not preventing every error through exhaustive upfront review but detecting errors fast and reversing them at the lowest possible cost. Reliable systems build this through three layered feedback mechanisms working in sequence: structural checks that block invalid outputs and return actionable fix instructions the agent can act on without human translation, runtime observability through logs and metrics that make execution visible to both agents and humans, and agent-led self-review that audits outputs before escalating only genuinely novel cases to a human expert. Layering all three creates a system that catches errors at the cheapest possible point in the pipeline rather than routing everything through a human approval queue that cannot scale.

Escalation itself must be triggered by specific, pre-defined conditions encoded in the harness, not left to the agent’s discretion. This prevents both under-escalation, where agents proceed when they should not, and the equally damaging pattern of agents interrupting human experts for routine decisions that automated checks could handle. Teams should build evaluation criteria that evolve as they observe how agents actually fail in production. The mistakes that matter most in a live environment are almost never the ones engineers anticipate before launch. The ultimate design goal across all of this is convergence: a harness mature enough that re-applying its constraint checks produces no further changes, and the system has reached a stable, rule-compliant state.

Critical Anti-Patterns

Understanding how these systems fail is as important as knowing how to build them. The most dangerous trap is silent state corruption, where an agent generates outputs that look structurally plausible but contain semantic errors that accumulate undetected until they cause cascading damage that is expensive to unwind. This failure is more insidious outside software because the feedback signals are slower and weaker than a failed build or broken test. A research synthesis agent that subtly misattributes sources, a clinical documentation agent that quietly introduces dosage errors, or a financial analysis agent that gradually drifts from regulatory definitions all represent silent corruption that looks fine on the surface until it does not. The problem gets worse when teams rely on the conversation history itself to track where the workflow stands, rather than maintaining a separate, explicit record of progress. When something goes wrong in a system built this way, there is no clean state to inspect or replay. The only record of what happened is buried in a thread of messages that the agent may have interpreted differently at each step.

When AI teams deploy multi-agent configurations without verification gates between handoffs, each agent’s small mistake becomes an input assumption for the next, producing catastrophically wrong final outputs from a chain of individually plausible-looking steps. A multi-agent insurance underwriting pipeline where a data extraction agent makes a small error, a risk scoring agent builds on that error, and a pricing agent compounds it further illustrates how quickly the damage accumulates and how difficult it becomes to trace back to its origin. When guardrails and oversight structures are absent from the start, technical debt accumulates faster than teams can address it. Retrofitting those controls after a production failure is dramatically more expensive than building even a minimal harness from day one. A persistent context document, a few structural checks, and a basic escalation rule is substantially better than none, and it provides a foundation for iterative improvement rather than a crisis-driven rebuild.

The Architect or the Bottleneck

Harness engineering emerged from software development because that is where autonomous AI agents hit production scale first, but the underlying problem it solves is not specific to code. Any domain deploying agents to handle complex, multi-step work with real consequences faces the same structural gap: a capable model is not a reliable system. Those principles are not specific to software. They apply with equal force to legal research, clinical documentation, financial analysis, and procurement, anywhere that errors compound and someone is ultimately accountable for the output. The names change. The structural requirements do not. The gap between a raw model and a reliable production system is bridged entirely by the environment built around it. That means every organization deploying AI agents faces the same choice software teams have already confronted: invest in the environment that makes agents reliable, or spend your time cleaning up after ones that are not.

Building this infrastructure requires upfront investment in time and discipline, but the alternative is a system that generates technical debt and silent errors at machine speed. A well-engineered harness is the only mechanism that allows an organization to capture the productivity gains of autonomous AI without sacrificing the safety and quality of its most critical operations.

Quick Takes

1. AI Committees: Accelerant or Anchor?

2. The New Rules of AI Information Architecture

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

What Is An AI Delegate?

OpenClaw arrived with little fanfare and quickly became the fastest growing open source AI project on record. At its core, OpenClaw is a personal autonomous agent framework. It is software that connects a large language model to your email, calendar, file system, messaging apps, and external APIs, then acts on your behalf across all of them simultaneously without waiting to be asked. OpenClaw did not just answer questions. It completed work. That distinction resonated immediately with developers and technically sophisticated early adopters who had grown frustrated with AI tools that stopped at the edge of a chat window.

The adoption rate outpaced the security reviews, and that gap mattered. OpenClaw’s open architecture made it composable and extensible, but it also made it trivially easy to deploy with over-permissioned access, no audit logging, and no vetting of community contributed skill modules. The documented ClawHavoc supply chain attack, in which malicious skills compromised thousands of installations, was a predictable outcome of consumer grade architecture deployed without enterprise grade controls. Industry analysts flagged the category as an unacceptable cybersecurity risk for enterprise use. None of the security alerts and warnings stopped adoption. The excitement around what OpenClaw enables simply outpaced concern about what it could expose.

What followed was a wave of systems that took the core concept of OpenClaw and addressed its roughest edges while extending its reach. Claude Code Channels embeds autonomous execution directly inside Anthropic’s interface, adding structured reasoning traces and tighter permission boundaries that make the system’s decision making more inspectable. NemoClaw targets local deployment on dedicated hardware, bringing meaningful on device performance to users in regulated industries who cannot route sensitive data through cloud providers. GenSpark Claw shifts toward a managed experience, abstracting away the complex container configuration and credential management that made raw OpenClaw inaccessible to non technical users. It also layers in role based access controls and compliance oriented audit trails. Together, these systems are converging on a new operational paradigm that deserves its own category name: the AI Delegate. Rather than functioning as traditional software, AI Delegates operate as persistent, action-taking systems that work on a human’s behalf across applications and time.

An AI Delegate (often functioning as ‘Digital Staff’) is built on the four core pillars of Intelligence, Memory, Architecture, and Governance, and is defined by the following key features:

• Goal-Driven Autonomy. Interprets high-level human goals, breaks them into sub-tasks, executes across connected systems, and retries or adapts when steps fail. The unit of value is a completed workflow, not a text response.

• Ambient Presence. Lives inside messaging platforms users already use, such as WhatsApp, Slack, Telegram, or iMessage, providing an always-on experience with zero friction or context-switching.

• Persistent Memory. Maintains long-term context across all sessions using systems like LanceDB and vector embeddings. Remembers preferences, past decisions, and ongoing projects without being re-instructed.

• Proactive Heartbeat Execution. Operates on scheduled cycles without waiting to be prompted: it runs briefings, audits, consolidations, and background tasks autonomously.

• Dynamic Tool Construction. Builds its own integrations and scripts on the fly when existing tools are insufficient. Capability surface expands with every new task encountered.

• Cross-System Orchestration. Coordinates actions across databases, APIs, file systems, CRMs, and external services within a single workflow, serving as the integration layer so the human doesn’t have to.

• Modular, Open Architecture. Separates the reasoning layer (LLM) from the execution layer (tools, APIs), facilitating model swaps, new integrations, and flexible deployment without vendor lock-in.

• Local-First Deployment. Runs on the user’s own hardware by default, keeping data under user control. Cloud-managed variants exist but local-first is the defining architectural option.

• Governed Identity and Delegation. Operates under its own scoped service identity rather than borrowed human credentials, utilizing explicit handoff maps to define what the agent owns, what requires human approval, and what is never delegated.

• Multi-Agent Collaboration. Architected for teams of specialized agents (planner, executor, validator) that delegate to one another, check each other’s work, and operate in parallel.

Crossing the Threshold to Enterprise Operations

The trajectory of these AI Delegates mirrors a familiar pattern in enterprise technology adoption. A tool emerges in the developer community, proves its value through grassroots experimentation, and eventually forces organizations to either adopt it deliberately or manage it as shadow IT. The emergence of managed platforms and no code interfaces signals that this category is moving toward professional users much faster than most organizations realize. The organizations that capture the most value from AI will not be those that ship chatbot wrappers around foundation models, but those that embed agent level autonomy into products capable of handling unstructured cross system tasks at scale.

Consider the work that currently requires a human to manually bridge between a CRM, an inbox, a calendar, and a data warehouse. Managing sales outreach, sorting customer issues, summarizing market research, and setting up new accounts all involve many moving parts, but they follow predictable rules that rarely require constant human oversight. They are exactly the kind of multi system, goal directed workflows that AI Delegates are architecturally built to own end to end. These systems do not just make existing tasks faster. They replace entire task bundles that previously required dedicated staff. Organizations that measure the value of AI Delegates by chat deflection rates or response times are using the wrong yardstick. The real return is measured at the workflow or role level, and the enterprises that internalize that distinction early will redesign operations around it rather than layering AI Delegates onto legacy processes that were never built for delegation.

Making AI Delegates genuinely enterprise grade requires closing a set of gaps that consumer deployments have not had to address. The documented ClawHavoc supply chain attack was not an anomaly. It was a preview of what happens when systems with broad tool access and cross system execution rights are deployed without enterprise controls. Responsible deployment demands treating AI Delegates as governed identities rather than simple software tools. They must be provisioned with their own scoped service identities, least privilege access, and continuous behavioral monitoring so security tools can distinguish agent activity from legitimate user behavior.

Furthermore, delegation must be formalized through explicit handoff maps that define exactly what the system owns end to end and where a human must review the work before the AI Delegate proceeds. Because a single error can propagate widely, enterprise architectures must also include sandboxed execution environments, explicit rollback mechanisms, and durable state management to handle branching and failure recovery. Finally, user interfaces must include trust calibration mechanisms that give humans an accurate picture of what the delegate is doing and why. Overconfidence in agent capabilities leads to under supervision, and under supervision is where the real enterprise liability lives. The organizations that move now to establish this governed, observable, and human in the loop infrastructure will define the competitive landscape.

Capable Today, Production-Ready Tomorrow

We are still in the absolute earliest days of the AI Delegate paradigm. These systems are already demonstrating real utility in automating complex, cross-system workflows, but their underlying architectures remain raw and require significant hardening before they can be deployed safely at enterprise scale. The immediate future of this category will not be defined by flashy new reasoning capabilities. It will be defined by the unglamorous work of enterprise readiness: formal security certifications, governed agent identities, durable state management, and the organizational habits that make delegation safe rather than just fast.

Looking ahead, the roadmap points toward standardized protocols for multi-agent communication, polished interfaces that replace brittle command-line setups, and deep interoperability with the enterprise data systems where real operational value lives.

🎗️See You in NYC!

Register Now

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The AI Visibility Playbook: Surviving the Shift from Search to Synthesis

More people are turning to AI chatbots instead of traditional search engines to find information online. Even Google now displays an AI Overview at the top of many search results to summarize answers directly. When search engines ruled the internet, search engine optimization (SEO) served as the primary tool for companies to manage their brand reputation and ensure digital visibility. Now that foundation models synthesize responses rather than pointing users to external pages, SEO is being updated. Business leaders are adopting new strategies to influence the underlying training data and retrieval mechanisms of these AI systems, with the goal of keeping their brands visible and, just as importantly, accurately represented.

The shift in digital visibility centers around Generative Engine Optimization (GEO). Unlike traditional optimization that targets link rankings, this practice aims to influence the neural patterns and retrieval logic of foundation models. The goal is to ensure generative AI systems select and accurately cite a brand when synthesizing responses. Several related terms fall under this umbrella. Answer Engine Optimization (AEO) is the process of optimizing content to fit the conversational nature of modern AI, making it more likely to be featured in direct, synthesized answers. Artificial Intelligence Optimization (AIO) acts as a broader catchall label for these practices. Meanwhile, some marketers use Large Language Model Optimization (LLMO) to describe the exact same goal of shaping internal model weights and training data. These terms are often used interchangeably, which reflects how early-stage and unsettled the field still is.

As these practices mature, they are fracturing into specialized domains and deeper conceptual frameworks. E-commerce GEO (E-GEO) explores whether product listings and reviews require distinct optimization tactics or if standard strategies work across all industries. Beyond mere visibility, practitioners are identifying new challenges like Discovery with Exact Definition. This concept highlights the gap between an AI retrieving brand information and actually representing it with contextual accuracy. A model can cite a company and still get it wrong. When that happens at scale, companies face what one researcher has called Dark Revenue Loss, the invisible financial damage and eroded customer trust that occurs entirely within AI-mediated conversations and never surfaces in standard analytics dashboards.

Addressing that invisible leakage requires more than content tweaks. A proposed architectural concept called GEO Core envisions a dedicated brand governance infrastructure layer, something analogous to a CRM but built to operate across retrieval-augmented generation (RAG) pipelines, chatbots, and AI agents, ensuring that what a model believes about a company matches what the company actually is. While I am not aware of any commercial implementations yet, this concept points toward a future where managing AI-mediated brand identity is treated as an enterprise infrastructure problem rather than a marketing one.

The AI Visibility Operations Playbook

We are still in the early days of this shift, but practitioners are already deploying concrete strategies to adapt. Here are some of the techniques teams are using right now to ensure their brands surface accurately in AI-generated answers.

Crawler access configuration. Before an AI can summarize your content, it has to be able to read it. Many legacy website configurations accidentally block AI-specific web crawlers like the ones used by OpenAI or Google. Fixing this by updating a site’s robots file to explicitly allow these bots is the lowest-effort, highest-leverage action a team can take today, and it should happen before any other investment in this space.

AI brand auditing. Teams must establish a baseline by directly querying chatbots to see how their brand is currently represented in terms of accuracy, sentiment, and framing. Commercial visibility toolkits from major search marketing platforms now support this kind of tracking across citation frequency and competitive positioning. Without this baseline you are optimizing blind, and most organizations are still skipping it.

Citation engineering. This technique involves writing content in self-contained blocks of 30 to 60 words that pair a specific data point with clear reasoning, so an AI can extract the passage directly without needing to reinterpret it. Research demonstrated that this structural approach can increase visibility in generative results by up to 40 percent. The uncomfortable implication is that the best-structured source often beats the most accurate one in AI-mediated information delivery.

Natural language FAQ optimization. Users talk to chatbots differently than they type keywords into a search box, and content needs to reflect that conversational reality. By auditing the exact phrasing people use when prompting AI systems and creating matching question-and-answer pairs, teams make it trivially easy for the retrieval system to select their content. Adding just three to five of these natural language questions to an existing page can meaningfully increase the probability of a direct citation.

Machine-readable structured data. Implementing schema markup translates human-readable content into explicit metadata that AI systems can parse with precision, signaling what a page is about, who wrote it, and how it should be classified. This is technical hygiene that has been standard SEO practice for years, but its value is amplified in AI retrieval contexts because generative systems benefit even more from explicit structural signals than traditional search crawlers did. If your content management system supports it, there is no defensible reason not to implement it.

Platform-specific ecosystem tuning. Treating all AI models as a monolith is a reliable way to underperform, as one large financial technology company recently discovered firsthand. Each AI provider has distinct data dependencies: optimizing for one major search-backed AI requires strong traditional SEO fundamentals, while optimizing for a video-integrated AI model requires well-structured video transcripts and active business profiles. Teams should maintain separate playbooks for each platform rather than assuming a single strategy transfers across all of them.

Distributed authority building. AI models look for consensus across multiple independent sources to determine what is credible about a company. Earning mentions, reviews, and coverage across authoritative publications and industry outlets provides the corroborating signals that increase a model’s confidence in citing your brand. This reframes traditional public relations as a direct optimization lever for AI retrieval, not just a brand awareness exercise.

Long-term training data seeding. Because foundation models are trained on massive public datasets, brands that maintain a consistent, high-quality presence across the open web are more likely to be inherently known by the model before any retrieval even occurs. To influence foundation models, teams should actively participate in community forums and secure a presence in structured databases like Wikidata and Wikipedia. This is a multi-year strategy, not a quick win, but the compounding effects across successive model generations make early investment disproportionately valuable.

Vectors of AI-Mediated Brand Identity

The optimization surface itself is quickly expanding well beyond text on a webpage. Because major AI platforms increasingly pull from diverse source types, strategy must grow to match: video transcripts need to be structured and accurate, image metadata needs to be clean and descriptive, and audio content needs to be organized for machine ingestion rather than just human listening. At the same time, as autonomous AI agents begin executing vendor evaluations and purchasing decisions on behalf of users, the relevant optimization target shifts from web pages to the tool-calling interfaces and data layers those agents actually query. The goal is no longer just helping a chatbot describe your company accurately. It is ensuring an autonomous system can find, evaluate, and transact with your business without friction or distortion.

The window to build this foundation is closing faster than most organizations recognize. Analysts project a steep contraction in traditional search volume by 2026, which puts these new capabilities on a path from optional to mandatory in a short timeframe. The urgency compounds because newer AI models are frequently trained on outputs from prior generations, meaning early interventions reinforce themselves over time. Accurate brand representation established in today’s training data creates a self-reinforcing advantage that late movers will find genuinely difficult to close. Measurement is also maturing: tooling that explains why a retrieval system preferred one document over another is moving from research pipelines toward commercial platforms, which means the discipline is shifting from educated guesswork toward something testable and repeatable. Organizations that begin building these competencies now will be the ones that remain visible and accurately represented as the transition accelerates.

Learn More

What Critics Get Right and Wrong About MCP

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

How to Stay Employable When AI Is Coming for Your Job

Over the past few weeks, I have had a lot of conversations with people who are genuinely worried about what AI means for their careers. Not just developers, but marketers, analysts, lawyers, and others who are starting to wonder how much of their job will exist in 2-3 years. The anxiety is real and not entirely misplaced. Psychiatrists studying AI-driven job loss are warning about something beyond the usual economic disruption: they argue that serial job loss and chronic occupational uncertainty threaten the psychological foundations of adult life in ways that income replacement alone cannot fix. That got me to sit down with Evangelos Simoudis for an unplanned podcast on exactly this topic. What came out of that conversation, and from the research I have been reading, is a practical list of things knowledge workers can do right now to stay valuable.

Subscribe now

1. Build a working rhythm with AI, not just a habit of using it. The most productive people in AI adoption studies are not the heaviest users. They have a disciplined loop: direct the AI, check what it produces, refine, repeat. Fully handing off complex tasks produces mixed results. Keeping judgment in your own hands consistently does better. Learn to prompt well, spot-check outputs, and iterate fast. That loop is the skill.

2. Treat verification as a primary skill, not a secondary check. Research finds that whether AI makes you more or less valuable comes down largely to how well you catch what it gets wrong. Workers who verify reliably produce better results. Workers who struggle tend to hand off too much, and quality drops even when the AI is performing fine. Small differences in verification ability lead to big differences in outcomes. If you cannot tell when AI is wrong, your employer will notice before you do.

3. Know when not to hand a task to AI. The best workflow is not always more delegation. Workers tend to over-rely on AI on harder tasks, which is exactly when AI is least accurate and mistakes are hardest to catch. Knowing when to use AI, when to verify carefully, and when to just do the work yourself is a genuinely valuable skill. Being fast with AI tools is not the same as being reliable, and employers are starting to tell the difference.

4. Spend more time defining problems than executing solutions. Workers whose main job is carrying out known procedures face the highest automation risk. The defensible position is upstream: deciding which problems matter, what constraints matter, and how success should be measured. If your job is mostly applying known steps to familiar problems, AI is coming for that work first. The durable skill is not just execution. It is setting direction.

5. Develop precision in articulating intent. Knowing what problem to solve is only half the job. You also have to describe it clearly enough that an AI cannot misread it: naming constraints, edge cases, and what a good result actually looks like before the work starts. This is already being called spec-driven development in software, but the skill is not technical. It looks the same whether you are a lawyer briefing an AI on what a clause must and must not allow, a marketer specifying tone guardrails before a campaign runs, or an analyst defining what the model should not infer. Vague intent produces vague output, and the gap shows up immediately in what comes back.

6. Develop systems thinking across the full business process. As AI handles more individual tasks, the premium shifts toward people who understand how an entire process fits together. Someone who only knows their corner of a workflow is more exposed than someone who understands the end-to-end process and can spot where AI belongs in it. In most organizations still figuring out AI adoption, this kind of thinking is rare enough to be a real differentiator.

7. Reframe AI as a colleague you manage, not a tool you operate. Software developers seeing the largest gains stopped treating AI as sophisticated autocomplete and started treating it as a team member: someone work gets delegated to, whose output gets reviewed, and whose limitations get planned around. This changes how you scope tasks and how you hold yourself accountable for results, because you are now the manager of the output. Similar workflows are likely to spread well beyond software into accounting, legal analysis, and other knowledge-work domains.

8. Invest in domain expertise that cannot be written down. Generic, codifiable skills are easier for AI to absorb and easier for employers to replace. The durable investment is deep knowledge of a specific process, environment, or problem set, the kind that comes from years of experience rather than reading a manual. Knowing which edge cases matter, which heuristics hold up, and which approaches work even though no textbook recommends them, that kind of tacit knowledge is hard for AI to replicate and hard for employers to substitute away. It compounds over time. Codified skills do not.

9. Make your actual contribution visible and verifiable. AI is flattening the visible difference between strong and average workers, and employers are responding by leaning harder on track records. Make your judgment visible: document the reasoning behind key decisions, write up problems you diagnosed that others missed, build a record of outcomes tied directly to your work. Polish is easy to fake now. Evidence of judgment is not.

10. Pay attention to how your work product is being used. Unlike published content, the expertise of most knowledge workers is not protected by copyright. There is a real and growing risk that employers are feeding internal work product into model training pipelines without clear frameworks for worker ownership. You do not need deep technical knowledge to track this, just awareness and a habit of following how your company’s policies around AI training data are evolving. It matters most for senior people whose accumulated know-how is quietly becoming part of someone else’s training data.

11. Prepare financially and structurally for a less stable career. Senior tech workers with 15-plus years of experience are already shifting toward financial resilience: larger cash reserves, lower fixed costs, and an expectation of more frequent job changes. It is also worth asking whether your skills could support splitting time across more than one employer. AI-driven productivity gains may reduce the total hours any one company needs from a given worker, even one who has adapted well. Treating your career as a portfolio of engagements is a reasonable hedge against that shift.

What This List Cannot Fix

This list is built for a specific scenario: that AI reshapes knowledge work substantially but does not eliminate the need for skilled people, or that we land somewhere in an uneven, messy middle. I will be honest, though. I lean toward the more disruptive end of that spectrum. The pace at which AI is compressing routine cognitive work, combined with how unprepared most institutions are for what comes next, makes me skeptical that individual adaptation alone will be enough for most workers. The list above is still worth working through. But it is worth being clear about what kind of response it represents.

Behavioral scientists use two terms that are useful here. The i-frame focuses on what individuals can do to navigate a problem within the existing system. The s-frame asks whether the system itself needs to change. This list is entirely i-frame: upskill, reposition, save more, adapt. Those are real and worthwhile moves. But if AI displaces knowledge workers at a scale that individual adaptation cannot absorb, what is actually needed are s-frame responses: updated labor protections and tax codes, serious retraining infrastructure, legal frameworks around worker ownership of AI training data, and political leadership willing to treat this as a first-order problem. None of that exists in coherent form right now. The affected population is large, the anxiety is real, and the political opening is sitting there unclaimed. AI’s impact on employment could easily become a defining issue in the 2028 presidential race. It will depend on whether a skilled political figure decides to make it one.

• Project Maven: A Marine Colonel, His Team, and the Dawn of AI Warfare. This book hit differently given everything unfolding right now: the Anthropic-Pentagon fallout, US strikes on Iran, years of cheap drones reshaping battlefields from Ukraine onward. It traces how AI went from a colonel lugging a laptop around Afghanistan to a system helping pick thousands of targets in an active war.

• Alone in Japan: A Journey to the Future. Japan is the canary in the coal mine for what’s coming at the rest of us: an aging, shrinking society grappling with demographic decline just as immigration is becoming politically toxic across the West. What makes this book so useful is that Japan may also be the testing ground for whatever comes next, from AI to robotics to reimagining how communities function with far fewer people.

• It’s on You. This book reframed how I think about individual action versus systemic change. The i-frame/s-frame distinction makes clear why nudges and personal responsibility campaigns so often let the real culprits off the hook. If you’re trying to understand why well-meaning policy keeps falling short, this is a good place to start.

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

Why Your AI Agents Need Engineering Instead of Best Practices

I remain optimistic about the impact agents will have on knowledge work. As I noted in an earlier article, fields shaped by clear rules and mature systems, including accounting and contract management, already look well suited to this kind of automation. But even if the opportunity is real, the practical reality is that AI teams are still learning how to build agents that work reliably in production. Moving from a fragile prototype to a dependable system requires more than a good prompt. It means thinking carefully about the underlying architecture. To see how these systems come together, it helps to break the stack into its main parts.

In a working AI agent system, three core components define capability and behavior.

• Tools are the individual actions an agent can perform: database queries, API calls, file operations, or code execution. They are the atomic operations that enable agents to reach out and interact with external systems.

• Skills operate at a higher level. They are reusable workflows that combine multiple tools with specific reasoning steps to accomplish meaningful business objectives like analyzing a contract or triaging support tickets.

• Context files like AGENTS.md work differently. Rather than adding capability, they define how the agent should think and act. They specify the agent’s role, decision-making guidelines, constraints, and the reasoning patterns it applies when facing choices.

This three-layer separation is practical: it lets you mix tools into different skills, and run those skills under different behavioral frameworks, without rebuilding core logic.

Production agent systems depend on several other components that matter just as much as the tools themselves. Memory systems maintain continuity across multiple turns, allowing agents to reference past decisions and context. Orchestration frameworks determine whether one agent or multiple specialized agents should handle a task. Planning modules help break complex goals into executable sequences. State management ensures context carries across interactions. Guardrails and permissions prevent misuse and enforce organizational policy. Monitoring and logging let you see what the agent actually does, which often differs from what you expected. These pieces work together. Without memory, the agent can’t maintain context. Without orchestration, it can’t coordinate complex work. Without guardrails, it risks policy violations.

Rethinking Coordination and Memory in Agent Systems

There is still a great deal of experimentation happening across all these tool categories. Orchestration is one area seeing intense activity as builders realize that early frameworks are often too rigid. Older systems force developers to map out every workflow in advance or rely on unstructured agent chats. New tools are filling this gap by offering more flexibility and control. Cord is a recent example that lets agents build their own task trees on the fly. It allows models to decide when to split work into parallel tracks or share context without needing a hardcoded plan. Emdash tackles orchestration from a workspace angle by letting developers run multiple coding agents in parallel across isolated environments. This eliminates the messy reality of juggling different terminals and waiting for a single model to finish its job.

One underappreciated cost of adding agents is coordination overhead. In many-to-many designs, that overhead can rise very quickly as the number of agents grows. Centralized orchestration can reduce some of that complexity, though it introduces its own bottlenecks. More agents also means more inference costs and more opportunities for compounding errors. Recent studies suggest that adding agents helps in some settings, especially when work can be cleanly decomposed, but it can also add overhead and even reduce performance when the single-agent baseline is already strong or the task is highly sequential.

Memory and context systems are also evolving to handle more than just conversational history. As I argued in an earlier piece, most current memory approaches are better at retrieving facts or preserving conversation than at helping agents repeat operational work reliably. To solve this, developers are moving toward operational skill stores or context file systems. It is less about chat history and more about procedural memory. Instead of overloading a prompt with endless documentation, these new systems save successful workflows as permanent procedures. The agent only loads the specific instructions it needs for the exact task at hand. This method turns temporary problem solving into reliable company assets while drastically cutting down on computing costs.

Moving From Art to Engineering in Agent Design

As teams adopt new memory and orchestration tools, they often inherit best practices before testing whether those methods actually help in their own environments. AGENTS.md is a good example. These simple repository-level files are meant to guide how coding agents behave inside a codebase. A recent study examined whether they deliver on that promise by testing coding agents on standard benchmarks and on a new benchmark, AGENTBENCH, built from real repositories. The results were not especially encouraging. Automatically generated context files reduced task success rates while increasing inference costs by more than 20 percent. Agents followed the instructions and explored the code more extensively, but that extra activity did not translate into better outcomes. Even developer-written files produced only modest gains.

Too many teams still build a workflow, run it a few times, decide it feels right, and ship it. That approach carries real risks. The standard practice in machine learning has long been to test each new component before adding it: does this actually improve results, and where does it now fail? The same logic applies to agent systems. The lesson from the AGENTS.md research is not that context files are useless. It is that adding any component - a guidance file, a new agent, a prompt change - should be treated as an engineering decision, not a default. Leo Meyerovich made this point well when he argued that teams get what they measure. In practice, that means defining clear evals for your own use cases and keeping only what improves results, whether the metric is task success, speed, safety, or cost. In agent systems, the question is not whether a recommendation sounds sensible. It is whether it improves performance in your setting.

Putting an AI agent into production means coordinating a stack of tools, skills, orchestration frameworks, memory systems, and guardrails. Developers and startups are still iterating quickly on this infrastructure, often in open source, and that experimentation is helping the field mature. But it is also easy to mistake architectural complexity for progress. As the evidence on context files suggests, simpler tools paired with rigorous evaluation will often beat a more elaborate setup that has not been tested against real work. Part of the problem is that the number of variables in a working agent system is larger than it first appears. Chunking strategy, embedding choice, retrieval method, prompt structure, context window size, and model selection all interact. Teams that rely on defaults and intuition across these variables are, in effect, guessing. Systematic evaluation does not have to mean testing every combination - but it does mean knowing which variables matter most for your specific use case.

Getting an agent ready for production means running computationally intensive experiments to find the right configuration. Having an AI platform that lets you run those experiments efficiently is a distinct advantage. Dean Wampler recently explored this in a new article on the PARK stack, an open source foundation built on PyTorch, AI models and agents, Ray, and Kubernetes. In the end, teams with scalable infrastructure and rigorous evaluation will be better positioned to solve real business problems.

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The Agentic Sweet Spot: Where AI Moves Fast and Humans Stay in the Loop

A recent Anthropic study on agent autonomy offers a clear preview of where knowledge work is headed. Anthropic analyzed millions of real interactions across their public API and Claude Code to see how people actually deploy autonomous systems. The catch is that their clearest view comes from Claude Code, where they can track longer workflows end to end. I treat their strongest takeaways as a snapshot of coding agents rather than a universal map of all professions. That distinction matters. Software development is the proving ground for autonomous work because it requires far less hand-holding. You can run tests, get immediate pass or fail feedback, roll back mistakes, and break large tasks into smaller steps using mature and well-defined tools.

Software is just the beginning of the story. To get a glimpse of what comes next, we can look at financial operations and contract management, two fields already governed by strict rules, standard templates, and mature systems. These domains serve as excellent test cases to answer a practical question: where can autonomous agents move fast, and where does human review remain essential?

Subscribe now

Accounting Through Rules, Systems, and Exceptions

Accounting shares many of the structural advantages that make programming agent-friendly. The work operates under explicit, codified standards and policies that act like shared constraints. GAAP, IFRS, and tax codes define how transactions should be treated and recorded. Tasks decompose naturally into discrete, well-scoped subtasks with clear inputs and outputs. Reconciling an account, calculating depreciation, classifying a transaction, or preparing a tax schedule each have defined parameters and specific rules to follow.

Many of the mechanical steps are verifiable. A reconciliation either balances or it does not. Once inputs and classifications are set, many calculations can be checked against explicit rules. A journal entry either posts correctly or generates an error. The existing tooling is mature: ERP systems, general ledger software, and tax platforms expose structured data and APIs. An agent can pull invoices, match them to purchase orders, flag exceptions, draft follow-up requests, and attach supporting documentation. In practice, this works best with strong access controls and a clear audit trail. Reversibility is present too, though with caveats. An adjusting entry can fix a misclassified transaction, but the downstream implications for reporting, audit trails, and regulatory filings raise the stakes compared to a simple code rollback.

The real friction point is data quality and process maturity. Agents work best when inputs are consistent, documentation is complete, and policies are explicit. In many companies, source data arrives messy: incomplete invoices, missing receipts, conflicting bank feeds. Accountants spend significant time reconciling these discrepancies manually. An agent helps most when the company has already standardized data collection and approval workflows. The accounting function already treats auditability and traceability as first-class requirements, which fits naturally with agent logging and transparency. The practical deployment model mirrors existing practice: agents handle routine posting, matching, and documentation gathering, while CPAs focus on judgment calls, exceptions, and sign-off.

Why Contract Operations Are Agent-Friendly

Legal operations quietly built the exact same building blocks that make software automation possible. Contracts are built from templates and clause libraries. Redlines are standard, and changes are easy to compare, much like code diffs. Many companies already operate with standard fallback terms, risk acceptance matrices, and approval workflows. This is basically a template-plus-rules setup that agents can navigate.

An agent can identify contract deviations from company standards, extract key obligations, flag risky or non-standard terms, propose edits with explanations, and route work by risk tier to the right approver. In contracts, correctness means the agreement matches the company’s standards and risk posture. Reviewers can assess this by examining the deltas rather than reading entire documents, spot-checking high-risk clauses, and enforcing policy gates. The field already has mature tools for document management, document versioning, and audit trails, which align well with agent logging and transparency.

Genuine negotiation, novel legal interpretations, and edge cases still require attorney judgment. The sweet spot for agents is high-volume, templated work where terms follow known patterns. This works best when the company has already standardized clause libraries and clear acceptance criteria. Process maturity is the main constraint. Firms that have standardized templates and approval matrices will see faster value from agents. Humans stay in the loop for negotiation, exceptions, and final sign-off. In practice, agents handle initial screening and propose edits. Routine revisions are handled by the team, with escalations to senior counsel for complex negotiations and policy decisions.

The new bottlenecks in knowledge work

Coding, accounting, and contract operations share a pattern that shows up in more places than we might like to admit. When a job has clear inputs, explicit constraints, and cheap ways to verify results, agents take over the mechanical steps while humans shift toward review, prioritization, and exception handling. The organizations getting real leverage are not the ones writing the cleverest prompts. They are the teams treating agents like a production system by writing crisp specifications, forcing clarity up front, and making it easy to verify outputs before they hit a codebase, a financial ledger, or a contract repository.

The harder challenge is how this reshapes the company itself. As execution becomes practically free, the bottlenecks move to integration, quality assurance, and judgment calls. The core work becomes managing risk and coherence across a massive volume of machine-generated output. This forces leaders to build robust monitoring tools and tighten oversight precisely as they delegate more. It also creates a structural talent crisis. The entry-level tasks that historically trained junior employees are exactly the jobs agents do best. Companies will soon have to preserve manual skills intentionally just to ensure they still have people capable of troubleshooting when the automated systems inevitably fail.

Call for Speakers Closes March 20th

Submit A Talk

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

How Teams Actually Use RL to Make Agents Reliable

I have had a longstanding fascination with reinforcement learning (RL) and have monitored its slow diffusion from research labs into enterprise production. Much of the recent activity remains concentrated among foundation model builders and teams with dedicated post-training capacity. They use RL after pre-training to make large models reliable at executing tasks, not just generating text. This includes training agents to operate business software like CRMs and ticketing systems, run commands in cloud terminals, extract structured fields from messy documents, and navigate realistic user interfaces. In a few frontier cases, RL is even driving closed-loop workflows where a model proposes an action, tests it in a simulator, and learns from the measured outcomes.

To better understand real-world demand, I recently examined job postings in key U.S. technology hubs that mentioned RL. The results show that adoption is broader than just research labs. As the chart below illustrates, RL appears most often alongside Generative AI (57%) and AI infrastructure (43%), followed closely by autonomous agents (23%). There is also a long tail of activity across search, robotics, computer vision, and predictive analytics. The chart below provides a clear view of these diverse application areas.

While the data spans a wide spectrum, the most dynamic category is AI Agents & Autonomous Workflows. This sector represents the shift from passive chatbots to active systems that can execute complex tasks. Below is a closer look at how engineering teams are deploying RL to build these agentic systems across eight distinct domains.

Subscribe now

Dynamic Revenue Optimization

In high-velocity environments like advertising and digital commerce, agents are replacing static rules with dynamic policies. Developers use contextual bandits to make split-second decisions on ad placement or pricing by learning directly from user clicks and conversions. The complexity lies in managing competing objectives. Through constrained reinforcement learning, these agents maximize revenue while strictly adhering to safety guardrails and budget caps. This approach allows systems to autonomously negotiate B2B transactions or adjust campaign bidding strategies in real time with less manual tuning day to day. In postings, this work is usually framed as bidding and budget policies, constrained optimization, and learning from advertiser or customer feedback when recommendations get accepted, rejected, or modified.

Autonomous Software Refactoring

Beyond simple code completion, agents are taking on deep software engineering tasks like language migration and vulnerability patching. The advantage here is objective feedback: compilers, tests, and deployment checks serve as verifiers. Agents receive negative rewards when code fails to build or pass assertions, creating a tight, iterative learning loop where the model refines its policy for code generation and refactoring until it produces correct solutions. This is especially valuable for long, interdependent workflows where order matters and early mistakes cascade. In job postings, this appears as autonomous debugging, test-driven agents, codebase migration automation, and policies that optimize for passing builds and safe rollouts.

Beyond Robotic Process Automation

In back-office settings, RL is often used to turn “tool use” into something closer to a dependable habit. Teams train agents on company-specific rules and tone using human feedback, then push further with offline RL that learns from logs of how skilled operators actually resolve cases. The RL signal is usually tied to outcomes practitioners care about, like fewer escalations, fewer retries, and clean completion of a workflow across systems such as HR, IT, finance, and CRM tools. In job postings, this tends to show up as agentic workflow automation, tool calling, human-in-the-loop review, and reward design that handles delayed outcomes.

Automated Red Teaming

Security teams are deploying agents to operate at machine speed for both defense and automated testing. Because security threats develop quickly and visibility is incomplete, agents must make decisions under uncertainty. Red team agents learn attack strategies in simulated environments while blue team agents learn to detect intrusions from incomplete alert data. This adversarial training discovers novel attack strategies and robust defenses that human analysts might miss during manual penetration testing. In job postings, this appears as autonomous incident response, continuous red teaming, adversarial training, and environments that let agents rehearse safely.

Deep Information Synthesis (including Deep Research)

For tasks requiring “System 2” thinking, such as comprehensive market research or legal synthesis, engineers employ process supervision to reward intermediate steps rather than relying solely on final outcomes. This encourages agents to gather evidence, cite sources, and recognize when they need to search further, instead of hallucinating plausible answers. The result is a system that follows verifiable paths while knowing when to keep searching. In job postings, this shows up as process supervision, evidence-based synthesis, citation quality, and workflows that explicitly train agents to avoid shortcuts.

Autonomous Supply Chain Management

Logistics and supply chain applications require agents to bridge the digital and physical worlds. Whether managing warehouse robots or routing delivery fleets, these systems treat operational choices as sequential steps that reshape the network. Routing decisions, for instance, ripple through fleet availability, queue lengths, and delivery windows. Since training on live hardware is prohibitively expensive and dangerous, teams rely on simulation-based training. Agents master complex control tasks before transferring policies to the real world, balancing competing objectives like delivery speed, fuel costs, and safety margins. In job postings, these topics show up around dispatch and routing policies, digital twins, sim-to-real transfer, and constrained control for robotics and autonomous systems.

Autonomous Scientific Discovery

In fields like pharmaceuticals and materials science, “scientist agents” close the loop between hypothesis generation and physical experimentation. They use active learning to navigate vast search spaces of potential compounds or materials. Because physical experiments are slow and expensive, teams typically train policies in simulation first and then use real experiments as high-value feedback. The core technical challenge is balancing exploration against exploitation: the agent must decide whether to refine a promising candidate or test a novel hypothesis, optimizing experimental design to maximize information gain while minimizing the time and cost of lab work. In job postings, the work shows up as closed-loop experimentation, lab robotics integration, simulation-driven training, and methods for balancing exploration with exploitation.

RL in the Agent Orchestration Layer

As agent ecosystems grow, infrastructure engineers are building the orchestration layers that manage them. The focus here is on the “agent runtime” where reinforcement learning optimizes how requests are routed to specialist workers. Rather than hard-coding which tool or agent to invoke and in what sequence, the system learns a policy based on success rates and constraints like latency and cost. Teams are also building evaluator agents that score plan quality, creating feedback loops where the orchestration layer continuously refines its coordination strategies based on actual task outcomes. In job postings, this looks like agent routers, planner-executor architectures, multi-agent coordination, evaluation frameworks, and guardrails that can be optimized over time.

These eight domains illustrate where RL appears in production agent systems. RL is one approach among several for improving reliability and decision quality. In previous work, we explored complementary techniques including evolutionary methods for discovering optimal agent architectures and structured observability that turns agent debugging from guesswork into measurable engineering. The common thread across these strategies is identical: moving from costly trial-and-error toward systematic, repeatable improvement.

Simulation First, Production Later: Safe RL Deployment Patterns

Across these domains, the technical patterns are surprisingly consistent. Most teams start with offline RL from production logs, because naive online exploration is risky when the “environment” is a real business process or a live system. From there, the work quickly becomes about constraints and rollouts. Policies are trained in simulation or test environments, they ship behind safety filters, and they graduate from “suggest” to “act with confirmation” to limited autonomy for routine cases. Reward design is rarely a single number: it is usually a bundle of outcome metrics with hard limits on things like budget, latency, and safety.

The market signal in the postings is not “more RL research.” There is demand for people who can connect RL ideas to production realities: instrumentation, evals that match business outcomes, careful guardrails, and integration with existing systems. If you are building agentic workflows, RL is showing up less as a magic upgrade and more as a way to learn better sequential decisions under real operational constraints.

Quick Takes

1. The Shift from Routine Execution to Spec-Driven Work

2. Orchestrating Multiple AI Agents: A Skill That Won’t Stay in Software Engineering

3. How to Protect Your Career When Your Output is Used to Train Models

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.

Subscribe • Previous Issues

The Honeymoon Phase Won't Last: Preparing for AI's Platform Shift

I am old enough to remember the early days of the internet. It was a time when blogs were everywhere and information felt decentralized. Before the giant platforms and their algorithms, the web felt like a collection of independent voices. We had chronological feeds we controlled, not algorithmic ones controlled by someone else.

AI is still in the honeymoon phase, when platforms over-deliver to build adoption. Internet history tells us what typically follows. Right now there’s a mad rush to lock users into a specific model, a specific app, a specific workflow. I get why companies are doing it. But the best models today are often comparable for real workloads, and open-weight options are close enough that tying yourself to one vendor’s roadmap is a choice, not a necessity. I’ve always preferred to keep my options open: use open tools when I can, swap components when I need to, and avoid building around the assumption that any one platform will always treat me well.

What follows is a set of early warning signs. Think of them as “don’t repeat the internet” signals for teams building AI products.

Designing for Exit While It’s Still Cheap

The first warning sign is when access to the core capability narrows over time. In AI, that can mean fewer technical details, fewer deployment options, and fewer ways to inspect or control behavior. You start by experimenting freely. Six months later, you can’t run anything locally, can’t audit what changed, can’t fork a model, and can’t make your own latency and cost tradeoffs. The vendor becomes your runtime, your roadmap, and your risk profile. You also inherit their update schedule. Many of us have noticed providers tweak models behind stable API names. Production applications need version-locking, regression test suites, and dashboards tracking output distributions to catch when behavior shifts overnight.

A second warning sign is policy volatility, often justified as safety measures. Terms of service and acceptable use policies can shift quickly, and enforcement can be inconsistent. The failure mode is not a clean error like traditional software. It’s silent refusals, degraded answers, or a workflow that works Monday and breaks Thursday with no code changes on your side. The model switches from verbose to terse, breaking parsing logic, or shifts output formats, breaking structured extraction.

A more awkward version of policy volatility is geopolitics. Providers can decide they cannot serve certain regions or certain industries, and suddenly your product stops working for those customers through no fault of your own.

Even legitimate use cases can fall into territory that makes providers nervous. Security analysis, healthcare applications, legal research can all trigger unpredictable restrictions, creating reliability problems that have nothing to do with your code quality. The internet version of this was “the algorithm changed.” The AI version is “the model decided it can’t help,” or the platform decided your use case is now out of bounds.

The practical move is to treat multi-provider support like an insurance premium, not a nice-to-have. Keep at least one viable fallback path. Avoid letting vendor-specific features, proprietary formats, or tool calling conventions become the spine of your product. Assume switching costs will be measured in months if you wait until you’re forced.

Keep Your Moat on Your Side

Another early warning sign is asymmetric data flow. Many providers use consumer chat data for model training or improvement unless you opt out. Enterprise and API data is often excluded unless you opt in. The risk is that teams still do real work in consumer chat surfaces, and their proprietary domain knowledge can end up improving a system their competitors can also access. For teams with deep specialized knowledge, repeated corrections and detailed examples can become a high-value signal that you are giving away for free, which can dilute your advantage over time.

Privacy raises a separate concern because context windows often contain sensitive information. When you paste code or customer details into an AI assistant, that data persists in the provider’s logs with specific retention policies. For developers using IDE integrations, the assistant might be seeing every file you open, not just the file you’re actively editing.

My rule of thumb is simple: treat AI input like you’re sending it to an external service you don’t control, because you are. Build guardrails into your code, not just your policy docs. Scan outbound prompts for secrets. Limit context to the minimum. For high-sensitivity workloads, the “right” architecture might include running an open model in your environment, even if you still use a hosted model for general tasks.

Build Like You’ll Switch, Because You Will

A subtler warning sign is the assumption that switching will be easy when you need to. Prompts that work cleanly on one model break on another. Tool calling formats differ. Output that’s reliable in one system gets flaky in another. Teams assume they can swap providers later, then discover that “later” means rewriting prompts, rerunning evaluations, rebuilding tool adapters, and retraining your team to work with a new model.

Embeddings and fine-tuning make this worse. If you build retrieval around one embedding model, moving means re-embedding your entire knowledge base and retuning your pipeline. If you fine-tune on a provider’s platform, you get an artifact that only works there. These techniques aren’t mistakes, but you need to price in the switching costs before you commit.

The practical move is to separate what your product does from which model you’re currently using. Put prompts, tool definitions, and routing logic behind a layer you control. Store conversation state in your own database, not in a vendor’s memory feature. Treat portability the same way you treat observability or backups: as a continuous discipline, not something you retrofit later.

Treat Token Costs as a Product Risk

Token-based pricing makes costs volatile. A prompt change, a longer context window, or a retry loop can spike your bill unexpectedly. Teams have seen cases where adding “explain your reasoning” to prompts doubled costs, or where a misconfigured chain-of-thought prompt made requests 50 times more expensive. You need real-time monitoring, rate limits, and circuit breakers from the start.

Beyond the bill spikes, there’s a longer-term pricing risk that should look familiar. Twitter’s API went from free and open to restricted and expensive. Google Maps had a cutover that forced billing and new keys, and many sites and apps saw maps fail until they reconfigured. Today’s AI API prices are likely below the true cost of inference, subsidized like Uber’s early rides. Amazon’s marketplace fees climbed from under 20% to over 50% once sellers were locked in. Token pricing could follow the same curve.

Rate limits and pricing tiers create different capability classes. Providers have strong incentives to degrade cheaper tiers over time while maintaining quality for premium customers. The economic logic is straightforward: inference is expensive, and the profit-maximizing move is to make lower tiers barely usable, pushing heavy users upward. Assume that whatever tier you’re on today will become worse unless you’re paying enterprise rates. Monitor model quality continuously, not just at launch.

There’s also a strategic risk that mirrors the platform era. Your provider can see your prompts and usage patterns, which tells them exactly where the valuable opportunities are. If they ship a competing feature, they start with your playbook. Meanwhile, advantages from clever prompting decay fast as models improve and competitors copy your patterns. The durable path requires something deeper: proprietary data, workflow integration, evaluation discipline, or distribution you control.

Don’t Let Convenience Become a Cage

A final warning sign is relying on a model’s internal knowledge as the sole truth for your application. Waiting for a provider to solve hallucination or complex reasoning is a trap that guarantees vendor lock-in. A recent example I found compelling is a tool called RealAI. They moved beyond simple document retrieval by fusing millions of disparate data points into standardized, queryable structured data. They also understood that foundation models still struggle with reliable math, so they wired their AI directly to dedicated financial calculators. When you move the actual intelligence into your own data pipelines and specialized external tools, you drastically reduce your dependency on any single provider. Your competitive advantage becomes your proprietary data fusion and business logic, which allows you to swap out the underlying language model whenever a better option appears.

These are early observations, not settled conclusions. The AI market is still taking shape. But the internet’s history suggests we should pay close attention to where incentives lead. We watched a handful of companies acquire their way to dominance the last time around. If we want a different outcome this time, we need early pressure for portability, transparency, user control, and actual antitrust enforcement before the defaults harden into something harder to change.

Some of that starts with the tools we pick. A concrete example from my own work: there’s real excitement around Claude Code right now, and I understand why. But I keep pointing people toward open tools that make model swapping normal. The setup I’ve been using is OpenCode paired with OpenRouter, which gives you access to different model providers without forcing you to rewrite everything when you want to try a different model. Internet platforms eventually moved to restrict the third-party tools that gave users more control. I’d rather adopt open tools now, while the window is open.

To be completely transparent, I still rely on proprietary models from Anthropic, Google, and OpenAI. A real performance gap remains between those systems and open-weights models. But that gap is narrowing quickly. You should actively explore offloading more workloads to smaller open-weights models that you can customize and augment with your own data and tools. While a startup can adopt this approach immediately, large organizations will naturally need to add layers for governance and compliance. The underlying goal is exactly the same for both. You must maintain optionality and keep control over your product.

Ethics.dev is our new sister site that tracks the practical impact of AI across fields like safety, labor markets, government regulation, and the economy. Bookmark this page for daily updates on how these rapid developments will reshape your industry. It is designed as a practical resource to help you keep up with the complex rules and economic forces shaping the future of AI.

Ben Lorica edits Ethics.dev and the Gradient Flow newsletter, and he hosts the Data Exchange podcast. He helps organize the AI Conference and the AI Agent Conference, while also serving as the Strategic Content Chair for AI at the Linux Foundation. You can follow him on Linkedin, X, Mastodon, Reddit, Bluesky, YouTube, or TikTok. This newsletter is produced by Gradient Flow.