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.

Subscribe • Previous Issues

The Industrialization of Synthetic Data

Synthetic data used to be a fairly narrow idea: pad a small dataset, test a model without touching production data, maybe stress a system for bias. The rise of generative AI and autonomous agents has changed the landscape. Teams use synthetic data to train and evaluate agentic systems, to cover rare failure cases, to meet privacy and compliance requirements, and to simulate workflows that look more like real work than like a benchmark. As the use cases expanded, the “just generate more rows” mindset stopped working, and synthetic data started to look like an engineering system that needs real infrastructure.

Compute intensive, in this context, means two things. First, the cost per synthetic example is going up because each example is longer, more interactive, and often requires multiple model calls. Second, the pipeline around generation is getting heavier: validation, deduplication, tool execution, sandboxes, storage, and orchestration. This complexity has effectively turned synthetic data generation into an industrial-scale engineering problem.

The unit of data got bigger
Modern synthetic data is no longer just a short question and answer. It has evolved into long sequences of steps that include planning, reasoning, and using external tools. At the same time, we are asking models to show their work by producing step-by-step reasoning traces. If a single high-quality training example now spans thousands of tokens and dozens of steps, you need far more computing power to produce it. This is especially true for AI agents that must try a task, fix their own mistakes, and finish a job rather than just giving a quick response.

One example now takes a small team of models
Many pipelines have moved from a single model call per example to a coordinated workflow of different agents. One agent might select a persona, another generates the content, and a third refines the tone. When you multiply this by millions of examples, the total number of inference calls scales rapidly. In practice, teams building research assistants or customer-support agents find that synthetic data generation is actually a complex set of separate inference jobs that require sophisticated scheduling and tracking.

Quality control became its own workload
Because these sequences can be long, checking the work is no longer a simple final check. A tiny mistake at the start of a plan makes everything that follows a waste of time. To catch these errors, teams now use a second AI to judge every single step the first one takes. If a task has twenty steps, you might run fifty separate AI operations just to get one usable result. When you scale that to millions of examples, the demand for processing power explodes.

“Trust but verify” requires running code
For agents that use tools, a frequent failure is when the model claims it finished a task but actually failed. To solve this, pipelines now include executable validators. This means running Python scripts or checking API returns in real time to see if the code actually works. This pushes the compute burden away from pure GPU inference and into CPU, memory, and sandbox capacity, often requiring thousands of parallel, isolated containers to verify that the generated data is actually correct.

Realism demands real tools and environments
If you want to teach an agent to browse the web or use enterprise software, you cannot simply fake the responses. Teams are increasingly executing real tool calls and managing the associated rate limits, timeouts, and connectivity. For “computer use” training, the cost jumps significantly because you are running full virtual machines with browser engines and GUI rendering. This looks less like a data script and more like operating a massive virtual desktop fleet.

Keeping data diverse is a heavy lift
Once you can generate data at scale, the bottleneck shifts to keeping that data varied. Production pipelines now generate massive numbers of candidate items, then use embedding models and clustering to deduplicate them aggressively. This requires large-scale embedding runs and significant compute spent on items that are ultimately discarded. This is a major hurdle for teams building enterprise copilots that need to handle a vast range of departments, personas, and edge cases without repeating themselves.

Higher-fidelity generators raise the per-sample price
In specialized fields like medical imaging, simple simulations are no longer enough. Generating high-resolution 3D images to train diagnostic AI requires advanced models that are much slower than older methods. Because training loops consume data faster than a single generator can produce it, teams often have to run massive GPU pools just to ensure the training process does not sit idle while waiting for the next batch of images.

Synthetic data is turning into an always-on factory
Static datasets go stale quickly for interactive agents. Modern systems use a continuous loop where the agent interacts with environments and logs new experiences throughout the training process. This means your demand for computing power does not end once the data is collected. It persists throughout the entire life of the model. Keeping training and generation in sync becomes a major systems engineering challenge, requiring a production-grade service with its own monitoring, fault tolerance, and distributed infrastructure.

Putting the Pieces Together: Synthetic Data in Production Mode

A system from Meta called Matrix shows how these requirements come together in a single synthetic data factory. It was built to create data for complex tasks like customer service and web research. These jobs require multiple AI agents to work together, which is much harder to manage than a simple question and answer script.

Matrix targets large-scale data generation where each “item” is not a single prompt-response, but an end-to-end workflow. Every task carries its own instructions and history as it moves between different AI agents. This design gets rid of a central controller that often slows things down. By letting each task move forward on its own, the system avoids the idle time that usually happens when computers have to wait for a large batch of work to finish.

The setup highlights how much infrastructure this requires. Matrix is built on an open-source stack (SLURM and Ray) and uses containerized execution (Apptainer) for tool and environment interaction, while compute-intensive operations like LLM inference and container workloads are handled as distributed services that can scale independently from the agents. In one test, the system handled over 12,000 tasks at once and produced 2 billion tokens of text in about four hours. For tasks that involve using real software tools, it can run 1,500 containers at the same time to verify that the results are accurate.

The rise of these data factories is another reason to modernize your AI infrastructure. Synthetic data pipelines now look like production systems that mix GPU-heavy generation and embedding runs with CPU-heavy filtering and tool execution. They also create a lot of read and write traffic as you iterate. A multimodal lakehouse is a sensible data layer for this work because it stores raw media alongside embeddings and features. It also feeds training and inference jobs without letting storage become a bottleneck that leaves GPUs waiting.

The compute side maps cleanly to the PARK stack. Kubernetes provides the cluster foundation and Ray coordinates the complex mix of distributed tasks to keep pipelines moving. PyTorch and your frontier models then handle the generation and training loops. This approach offers a practical way to treat synthetic data as a core part of your platform. It provides a durable place to store and query what you generate and a reliable way to scale the services that produce it.

Building these data factories does more than just improve reasoning and agent behavior. It provides the scale needed to train models on the multi-table databases that most companies rely on. Done well, synthetic data ceases to be a stopgap and becomes a practical path to better business models, including things like churn, fraud, and forecasting.

You Don’t Need a Massive ML Team to Scale AI Affordably

As generative AI applications mature, engineering teams are finding that standard API endpoints often fall short on cost and performance. Companies increasingly need to customize and scale their own AI workloads to remain efficient. A recent engineering blog post from Notion illustrates this shift perfectly. To handle billions of vector embeddings, Notion overhauled its infrastructure by migrating both indexing and serving to Ray. The company noted that while tech giants build entire internal teams around open-source projects like Ray, Notion does not have a dedicated machine learning infrastructure team. Instead, they rely on a managed service from Anyscale to access these same enterprise-grade capabilities. Just as we saw with synthetic data pipelines, this migration is the PARK stack at work. By adopting these interoperable open-source compute components, teams can efficiently pipeline CPU and GPU tasks, run open-weight models directly, and drastically reduce latency without being locked into a single vendor.

Learn More

Ben Lorica edits the Gradient Flow newsletter and 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 Bubble Is Real. Enterprise Usage Is Even More Telling.

The existence of an AI bubble is beyond dispute. What remains unclear is when or how it deflates. As investors know all too well, the most costly mistake in business is often being correct prematurely. The infrastructure layer has already booked revenues. This includes sectors like semiconductors, data centers, and power grids. The application side is a different story. It’s still a guessing game, and we’re still trying to figure out what customers will actually open their wallets for.

Rather than attempting to time the correction, I try to focus on what enterprises are actually doing with AI in production. When you look at what’s actually happening, the reality doesn’t quite match the headlines. It’s no secret that coding is the big winner so far, but the real news is the growth in administrative automation, and a clear preference for “simple and reliable” over “flashy and complex.” Furthermore, Chinese AI firms are pivoting aggressively toward Western markets, introducing application-layer competition to segments where U.S. firms have focused primarily on foundational research. Ultimately, we’re seeing two very different playbooks. Major Western AI labs are all-in on reaching AGI, but China is doubling down on the essentials: energy, supply chains, and diffusion — getting AI apps into the hands of as many companies as possible, as fast as possible.

Dominant Use Cases: From Code to Creative to Administrative

Software development is the dominant enterprise workload, rising to over half of total token usage by late 2025. AI-assisted programming and coding tasks include debugging, refactoring, and resolving bugs. Developer adoption ranges from half to two-thirds using AI tools daily, significantly increasing the velocity of the entire software lifecycle. A common pattern has emerged: teams start with IDE copilots, then move up the stack into codebase Q&A, automated PR review, and “issue-to-patch” workflows that draft changes a human can validate.

But two other areas are quietly taking off just as fast: creative applications and administrative automation. Creative use has surprised many AI teams. It isn’t just about getting the AI to write a document. It’s more like a back-and-forth process where you build ideas together. This shows up in tasks like creating different versions of an ad, tuning product copy, or even scripting training scenarios.

Automating admin work is a huge deal for the bottom line, mainly because AI is now handling complex chores rather than just writing messages. AI is taking over the “busy work” of data entry and invoicing. Tasks that used to take all afternoon, like organizing insurance files or prepping financial entries, are now done automatically and handed to a human just for a final look. By automating sales tasks like record updates and follow-up sequences, AI removes the burden of manual data entry and administrative overhead.

There is also a massive shift happening under the hood. While everyone focuses on chatbots you can talk to, some of the most successful AI deployments are happening in the “plumbing” of the business. I’m hearing about more teams using agents for high-repetition tasks in data engineering and DevOps. These agents handle the tedious work of moving data between systems or keeping infrastructure running. It’s the kind of work end users never see, but it’s where the real gains in speed and automation are being made.

The Evolution of Inference Patterns

The technical architecture of AI is transitioning from single-pass pattern matching, to multi-step reasoning. New reasoning models are driving this shift. Because they allow a system to “think” before it responds, we’re seeing a total shift in the way these models use tokens. This has led to a dramatic increase in prompt lengths as developers build more complex, agentic loops. While the narrative around “autonomous agents” often outpaces the reality of production environments, there is an undeniable trend toward workflows where models plan and iterate rather than simply predict the next word.

In this architectural shift, open-weight models have carved out a stable and significant niche. Chinese models, such as DeepSeek and Qwen, have become formidable competitors, often providing performance that rivals proprietary Western models at a fraction of the cost. The strategic implication isn’t just cheaper inference. Chinese firms are using their open-weight models as a foot in the door for Western markets. Once they’ve proven their tech is legit through open-source, they move quickly into building business apps rather than just focusing on foundational models.

Deployment Patterns: Bounded Agency and Lifecycle Management

In the real world, the most successful companies are using what I call “bounded agency.” Even though we have the tech to build fully autonomous agents, most teams are choosing to keep them on a short leash. They limit the AI to just a few steps before a human has to step in and check the work. The reason is simple: reliability. By keeping a human in the loop, you ensure that if the AI makes a mistake, you can actually see what happened and fix it. This is about helping experts do their jobs faster, not replacing them.

Most teams are also choosing stability over perfection. They’d rather use a standard, off-the-shelf model with good guardrails than spend months trying to fine-tune a “perfect” custom one. It’s more practical and much easier to manage.

A related trend is a pattern I call "scaffold and shrink." Companies use a top-tier model as a temporary architect during the development or "vibe coding" phase. This expensive model writes the application code, refines the prompts, and generates the data needed to tune the system. Once the logic is solid, the team swaps it for a much smaller and faster model for daily use. This approach turns the high cost of a frontier model into a one-time development expense rather than a permanent tax on every customer interaction. It also levels the playing field. A small startup can use the best intelligence on the market to build its product without paying for that intelligence every time a user clicks a button. You do not need to run a massive model constantly if you have already used one to figure out exactly what your system needs to do.

The companies seeing the biggest returns tend to do two things well. First, they integrate AI deeply into their daily workflows. Instead of just using a chatbot, they turn general tasks into standard steps, like automatically updating a CRM right after a meeting. They then share those patterns across the whole company so everyone benefits. Second, they treat model upgrades as an ongoing process. They run old and new models side-by-side to catch any weird changes in behavior. They also build smart routing strategies so they aren’t using the most expensive model for every single tiny task.

This is where the competition is really heating up. New players, especially from China, are arriving with ready-to-use apps that promise instant results. This puts pressure on established companies to prove they can offer more than just a quick fix. They have to show that their systems are more secure, better integrated, and more reliable for the long haul.

Reliability and Infrastructure Gaps

Reliability is still the biggest hurdle for businesses today. Even with the top-tier foundation models we are all using right now, the success rate drops fast as soon as you give an AI agent a long, multi-step task. Think about a customer support agent trying to handle a refund. It has to look up a customer ID, check a return policy, initiate a bank transfer, and then send a confirmation email. Even if the AI is 90% accurate at each individual stage, the chances of the entire sequence working perfectly are surprisingly low. This “compound error” effect basically cuts the hype around productivity in half and is the main reason we can’t give these systems full autonomy in a production environment.

There is also a massive gap between coding and other types of work. AI is great at coding because it gets immediate feedback from a compiler. It knows right away if the code works or not. But for complex tasks like insurance authorizations or incident response, the feedback loop is much slower. You don’t find out if the AI made a mistake until much later, and those real-world consequences are much harder to automate.

AI also breaks the traditional way we build and test software. Normal software is predictable, but AI is not. It can be a bit random, which means most teams can’t rely on their usual automated testing and have to check the work manually. This creates a lot of friction, and it’s made worse by the massive increase in data being processed. Prompts have grown four times larger because these agent loops require thousands of tokens just to complete a single task.

Finally, there is a hidden risk in how concentrated AI usage has become. Most companies are using AI for the same ten things, like fixing software bugs. This creates a “single point of failure” for the whole business. If a model’s performance degrades or a provider has an outage, it wouldn’t just be a minor glitch. It could paralyze core operations across the entire company.

Trust, Cybersecurity, and Geopolitical Considerations

Trust and safety aren’t just about ethics anymore. They are a business requirement. Trust failures show up as delayed deployments and worse outcomes, especially when they involve concerns around privacy, safety, and governance. Many organizations are effectively trying to scale autonomy before they’ve standardized policies for permissions, audit, incident response, and supplier risk. (I covered agents and security shifts in a previous article.)

Data sovereignty is also reshaping governance decisions. Buyers increasingly prioritize model origin and data residency, which influences vendor selection and hosting architecture. This is particularly relevant as Chinese startups expand into the West: enterprise buyers will demand more rigorous proof of control, transparency, and compliance before trusting these providers with sensitive, high-impact workflows.

The Margin Paradox and Market Correction

As AI tools become common, the industry is running into a bit of a trap. When everyone has the same efficiency-boosting tech, the savings just get passed on to the customer. This leads to lower prices and thinner profit margins for everyone. This deflationary cycle is being accelerated by the arrival of Chinese firms like Manus and Atoms. These companies add competitive pressure precisely in the application layer where monetization remains most uncertain, bringing sophisticated tools and outcome-driven approaches honed in brutal domestic competition.

We all recognize that a market correction is unavoidable, and because AI is now a large share of the market narrative, the spillover won’t be neatly contained. Infrastructure suppliers are partially insulated. Capital spent on hardware is a sunk cost once it’s booked, so any adjustment is more likely to show up as slower growth than revenue reversals. But there is a major caveat here. Much of the massive data center build-out is being funded by debt. If the application side doesn’t start generating enough cash to cover those loans, that debt could turn a simple market slowdown into a much deeper financial strain for the companies building the physical foundations of AI. Cloud revenue, meanwhile, remains largely tied to basic compute and storage rather than AI-specific offerings. The challenge for investors is that while a few durable winners will emerge, trying to spot them today is more about following the crowd than how these businesses actually make money.

Eventually, the bubble will burst, but that doesn’t mean the technology will stop being useful. History shows that once the hype dies down, the real work of “diffusion” begins as these tools become a standard part of every industry. That’s why I focus on what enterprises are actually doing today. By learning from the patterns that are working in the real world, you can move past the hype and start building AI projects that actually deliver results.

• Reader Bot: What Happens When AI Reads and Why It Matters. I still think nothing beats curling up with a good book, but we are facing a perfect storm where long-standing declines in reading meet AI’s ability to process text for us. This book offers an excellent overview of how to use these models as helpful co-readers without outsourcing the actual joy of reading.

• I Deliver Parcels in Beijing. Years ago in Shanghai I kept dodging electric scooters zipping around the French Concession to make deliveries, and it turns out that was just the tip of the iceberg. This book puts you inside the life of the person on that scooter, where every bathroom break has a cost in yuan and every failed delivery eats into wages that were already razor-thin.

• Strangers: A Memoir of Marriage. I've read a lot of memoirs over the years, and this is one of the best. It is a sharp look at how little we sometimes know the people closest to us.

Ben Lorica edits the Gradient Flow newsletter and 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 Operational Memory, Not Just Conversational Memory

Now that AI agents are moving out of the lab and into the real world, we’re realizing that “memory” isn’t one-size-fits-all. Most people think of agent memory like a personal assistant. It remembers your preferences, your travel plans, and the email you composed last week. This is great for a research copilot or a personal coach where the goal is a long-term relationship.

But if you’re deploying agents to handle back-office operations like fixing data pipelines or managing APIs, you don’t need a persona. You need reliability. I started looking into this because I saw teams struggling to make agents work in high-stakes, repetitive environments. In these cases, the goal isn’t conversational flair. Instead, it’s making sure the agent doesn’t have to reinvent the wheel every time it performs a task. By separating how an agent “thinks” from how it “acts,” we can finally scale automation without the massive costs and unpredictability that usually come with it.

Constraints of Infinite Context and the Limits of Modern Transformer Architectures

In a production environment, the "just add more context" strategy hits a wall very quickly. Even though context windows have grown massive, the math behind them is still expensive. Because computational work grows quadratically with input length, the more information you dump into a prompt, the slower the agent gets. A task that should take one second can balloon into thirty seconds just because the context is too large. There is also the “lost-in-the-middle” effect to worry about. When prompts get too long, agents often lose track of the information buried in the center. Research shows that giving an agent small, focused snippets is often twice as accurate as making it read a giant document.

Beyond the technical overhead, there is a structural problem with how agents handle enterprise infrastructure. If you have hundreds of internal tools and APIs, describing them all can eat up your prompt’s token budget before the agent even starts its work. Most importantly, today’s architectures don't allow for organizational learning. Every time an agent runs a task, it treats it like a brand new puzzle. It pays the full "thinking cost" of planning and discovery every single time. Without a way to save and reuse a successful workflow, the system never gets faster or cheaper. It just stays stuck in a loop where the 1,000th execution is just as difficult as the first.

The root of this problem is that we are treating the agent’s context window like RAM: a volatile workspace that wipes clean the moment a task is finished. In a traditional computing stack, you wouldn’t reload your entire operating system every time you wanted to open a text file. But in the current agent paradigm, we force the model to “re-boot” its understanding of our infrastructure for every single request. This creates a massive Context Tax — a recurring overhead where you pay in both latency and tokens to re-teach the agent things it should already know.

The Attention-Window Workarounds: Current Memory and Context Architectures

Most current ways of handling agent memory focus on finding information rather than reusing successful actions. Take Retrieval-Augmented Generation (RAG) for example. It is great at fetching facts to help an agent answer a question. This helps avoid the "lost-in-the-middle" problem. But RAG is built to find documents and not to remember how a job was actually done. It can find a technical runbook for you. However, it cannot remember that a specific five-step sequence of API calls fixed a database issue last week. Every time a workflow starts, the agent has to read documentation and plan its steps from scratch.

More advanced agent orchestration frameworks try to fix "catalog bloat" by loading tool definitions only when they are needed. This saves money on tokens, but it still doesn't help the organization learn. Other systems focus on "stateful continuity." This ensures an agent remembers who you are and what you like over several months. That is perfect for a personal assistant, but it doesn't help with operational tasks. If an API is broken or a tool description is confusing, the agent will just keep making the same mistake every time it runs. We also see agents that write code on the fly. This often leads to "workspace chaos" where you end up with hundreds of one-off scripts that nobody has verified or tracked.

In the end, current memory methods force agents to remain in a state of perpetual improvisation. Because there is no way to “crystallize” a successful solution into a reusable procedure, the organization never develops an institutional learning curve. To really scale in an enterprise, agents need to stop just managing what is in their immediate context and start building a permanent library of proven procedures. This transforms one-off successes into reliable, repeatable assets.

The Context File System: Memory for How Work Gets Done

To fix these structural bottlenecks, we are seeing the rise of what dex calls a Context File System (CFS). You might also hear this more broadly categorized as an Operational Skill Store. This architecture separates the expensive reasoning of a large language model from the actual storage of operational knowledge. It mirrors the way a mature engineering team works. Senior staff solve a novel problem once and then document the solution in a runbook so the task becomes routine. By turning successful executions into permanent and reusable procedures, a CFS transforms agents from improvisational tools into reliable enterprise infrastructure.

This architecture shifts the role of the context window from a temporary, volatile buffer to a persistent storage layer. Rather than stuffing a prompt with “just-in-case” information, a CFS allows the agent to “mount” and “unmount” specific operational volumes as needed. For example, an agent can mount a specific codebase volume to understand a bug, then swap it for a technical runbook volume to execute the fix. This “Context-as-a-Service” model ensures the agent’s focus is always high-density and low-noise, treating context as a managed resource rather than a fleeting byproduct of a conversation.

This approach fundamentally changes the economics of AI. In traditional systems, the 1,000th execution of a workflow costs as much as the first because the agent has to re-plan the task from scratch. With a CFS, the first execution pays an "exploration cost" in tokens. Every run after that simply replays the proven procedure. This often reduces token consumption by over 90 percent. It also solves the problem of "tool sprawl." Instead of stuffing a prompt with hundreds of API definitions, the CFS indexes these capabilities externally. It only loads the specific documentation required for the task at hand. This ensures that agents remain fast and accurate even as your company infrastructure grows in complexity.

A Context File System or operational skill store is defined by a few key features:

• Persistent Procedural Memory. Successful multi-step workflows are captured as versioned and executable procedures. These can be reused across the organization to eliminate the need for repeated planning.

• Indexed Tool Discovery. Rather than forcing an agent to memorize a massive tool catalog, the system maintains an external index. It only exposes relevant API schemas when they are actually required for the current task.

• Separation of Reasoning and Execution. High-cost model reasoning is reserved for genuinely new problems. Routine work is handled by the memory layer instead. This shifts the cost curve so that the system gets cheaper as usage scales. You stop paying for the model to “re-reason” through a solved problem, effectively turning a variable cost into a fixed, reusable asset.

• Self-Healing Infrastructure. The system monitors the success rate for every learned procedure. If an underlying API changes and a workflow begins to fail, the system automatically pulls the procedure and triggers a re-learning phase.

• Model and Vendor Independence. Procedures are stored as standard executable code rather than proprietary prompt formats. This allows your organizational knowledge to remain portable even if you switch AI providers.

• Governance and Auditability. Every action is recorded in an episodic memory layer. This provides the full execution traces and version control necessary for debugging in regulated environments.

Beyond immediate cost savings, the CFS provides a way to compound organizational value. Knowledge gained by one agent execution becomes an immediate asset for the entire enterprise. This creates a self-maintaining model that adapts to changing infrastructure without requiring manual prompt engineering. It allows AI agents to function as a stable and scalable part of the modern software stack.

Roadmap for Operational AI and Enterprise Agent Deployment

The future for Context File Systems like dex points toward a central hub. This is an internal registry where a workflow discovered by one team becomes instantly available to the whole company. In this model, a successful solution becomes a company asset that is versioned and governed just like standard IT code. Future versions will likely have better self-healing capabilities. They will be able to tell the difference between a temporary network error and a permanent change to an API. This evolution turns AI infrastructure from a series of isolated experiments into a library of expertise that gets more cost-effective as it grows.

For AI teams, the relationship between a Context File System and the Model Context Protocol (MCP) is a foundational choice. While MCP provides the standardized plug that lets agents connect to internal systems, a CFS acts as the layer that makes that connection economically viable. Without a CFS, a large-scale MCP deployment risks falling apart under the weight of its own tool catalog.

Organizations should prioritize stateful memory systems when the main goal is conversation and personalization. This is perfect for research copilots or personal assistants. On the other hand, a CFS architecture is the better choice for high-repetition operational work like DevOps automation or data engineering. In those environments, the goals are cost predictability and the reuse of proven procedures.

Quick Takes

1. The Economics of Robotaxis: Are We There Yet?

2. The “Data Center Rebellion” has gone national

Ben Lorica edits the Gradient Flow newsletter and hosts the Data Exchange podcast. He helps organize the AI Conference, the AI Agent Conference, the Applied AI Summit, 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 Chips: The Local Politics of AI Infrastructure

Even the most ardent cheerleaders for artificial intelligence now quietly concede we are navigating a massive AI bubble. The numbers are stark: hyperscalers are deploying roughly $400 billion annually into data centers and specialized chips while AI-related revenue hovers around $20 billion — a 20-to-1 capital-to-revenue ratio that stands out even in infrastructure cycles historically characterized by front-loaded spending. To justify this deployment on conventional investment metrics, the industry would need a step-change in monetization over a short window to make the numbers work.

While venture capitalists and tech executives debate the “mismatch” between compute and monetization, a more tangible crisis is unfolding far from Silicon Valley. A growing grassroots opposition to AI data centers remains largely below the radar here in San Francisco. I travel to Sioux Falls, South Dakota a few times a year to visit my in-laws. It’s not a region known for being anti-business. Yet even there, a “data center rebellion” has been brewing. Even though the recent attempt to overturn a re-zoning ordinance did not succeed, the level of community pushback in the heart of the Midwest signals that these projects no longer enjoy a guaranteed green light.

Subscribe now

This resistance is not merely reflexive NIMBYism. It represents a sophisticated, multi-front challenge to the physical infrastructure AI requires. For leadership teams planning for the future, this means "compute availability" is no longer just a procurement question. It is now tied to local politics, grid stability, water management, and city approval processes. In the course of trying to understand the growing opposition to AI data centers, I’ve been examining the specific drivers behind this opposition and why the assumption of limitless infrastructure growth is colliding with hard constraints.

The Grid Capacity Crunch and the Ratepayer Revolt

AI data centers function as grid-scale industrial loads. Individual projects now request 100+ megawatts, and some proposals reach into the gigawatt range. One proposed Michigan facility, for example, would consume 1.4 gigawatts, nearly exhausting the region’s remaining 1.5 gigawatts of headroom and roughly matching the electricity needs of about a million homes. This happens because AI hardware is incredibly dense and uses a massive amount of electricity. It also runs constantly. Since AI work doesn't have "off" hours, power companies can't rely on the usual quiet periods they use to balance the rest of the grid.

The politics come down to who pays the bill. Residents in many areas have seen their home utility rates jump by 25% or 30% after big data centers moved in, even though they were promised rates wouldn't change. People are afraid they will end up paying for the power company's new equipment. This happens when a utility builds massive substations just for one company, but the cost ends up being shared by everyone. When you add in state and local tax breaks, it gets even worse. Communities deal with all the downsides of the project while the financial benefits are eaten away by tax breaks and credits.

The result is a rare bipartisan alignment around a simple demand: hyperscalers should pay their full cost of service. Notably, Microsoft has moved in that direction publicly, committing to cover grid-upgrade costs and pursue rate structures intended to insulate residential customers — an implicit admission that the old incentive playbook has become a political liability (and, in some places, an electoral one).

Water Wars and the Constant Hum

High-density AI compute generates immense heat, requiring cooling systems that can consume millions of gallons of water daily. In desert municipalities like Chandler, Arizona, and Tucson, this creates direct competition with agricultural irrigation and residential drinking supplies. Proposed facilities may withdraw hundreds of millions of gallons annually from stressed aquifers or municipal systems, raising fears that industrial users will deplete wells serving farms and homes. Data center developers frequently respond with technical solutions like dry cooling and closed-loop designs. However, communities have learned the trade-off: dry cooling shifts the burden to electricity, and closed-loop systems still lose water to the atmosphere and require constant refills. The practical outcome is that cooling architecture is now a first-order constraint. In Tucson, a project known locally as “Project Blue” faced enough pushback over water rights that the developer had to revisit the cooling approach midstream.

Beyond resource consumption, these facilities create a significant noise problem. Industrial-scale cooling fans and backup diesel generators create a “constant hum” that represents daily intrusion into previously quiet neighborhoods. In Florida, residents near a proposed facility serving 2,500 families and an elementary school cite sleep disruption and health risks as primary objections, elevating the issue from nuisance to harm. The noise also hits farms hard. In Wisconsin, residents reported that the low-frequency hum makes livestock, particularly horses, nervous and skittish. This disrupts farm life in a way that standard commercial development just doesn't. This is why municipalities are tightening requirements: acoustic modeling, enforceable decibel limits at property lines, substantial setbacks (sometimes on the order of 200 feet), and berms that are no longer “nice-to-have” concessions but baseline conditions for approval.

The Jobs Myth Meets the Balance Sheet

Communities are questioning whether the small number of jobs created is worth the local impact. Developers highlight billion-dollar capital investments and construction employment spikes, but residents focus on steady-state reality: AI data centers employ far fewer permanent workers per square foot than manufacturing facilities of comparable scale. Chandler, Arizona officials noted that existing facilities employ fewer than 100 people despite massive physical footprints. Wisconsin residents contrast promised “innovation campuses” with operational facilities requiring only dozens to low hundreds of permanent staff — mostly specialized technicians — making the “job creation” pitch ring hollow. When a data center replaces farmland or light manufacturing, communities weigh not just direct employment but opportunity cost: lost agricultural jobs, foregone retail development, and mixed-use projects that might generate broader economic activity.

The secretive way these deals are made is often what fuels the most anger. A recurring pattern is what some call the “sleeping giant” dynamic: residents learn late that officials and developers have been negotiating for months, often under NDAs, sometimes through shell entities and codenames. In Wisconsin, Microsoft’s “Project Nova” became a symbol of this approach; in Minnesota’s Hermantown, a year of undisclosed discussions triggered similar backlash. In Florida, opponents were furious when a major project was tucked into a consent agenda. Since these agendas are meant for routine business, it felt like a deliberate attempt to bypass public debate. Trust vanishes when people believe advisors have a conflict of interest, like a consultant who seems to be helping both the municipality and the developer. After that happens, technical claims are treated as nothing more than a sales pitch. You won't get people back on board until you provide neutral analysis and commitments that can actually be enforced.

From Zoning Fight to National Constraint

What started as isolated neighborhood friction has professionalized into a coordinated national movement. Opposition groups now share legal playbooks and technical templates across state lines, allowing residents in “frontier” states like South Dakota or Michigan to mobilize with the sophistication of seasoned activists. The financial stakes are real: between April and June 2025 alone, approximately $98 billion in proposed projects were blocked or delayed, according to Data Center Watch. This is no longer just a zoning headache, it’s a political landmine. In Arizona and Georgia, bipartisan coalitions have already ousted officials over data center approvals, signaling to local boards that greenlighting a hyperscale facility without deep community buy-in can be a career-ending move.

The opposition is also finding an unlikely ally in the energy markets. While the industry narrative is one of "limitless demand," the actual market prices for long-term power and natural gas aren't spiking, but are actually staying remarkably flat. There is a massive disconnect between the hype and the math. Utilities are currently racing to build nearly double the capacity that even the most optimistic analysts project for 2030. This suggests we may be overbuilding "ghost infrastructure." We are asking local communities to sacrifice their land and grid stability for a gold rush that the markets themselves don't fully believe in.

This “data center rebellion” creates a strategic bottleneck that no amount of venture capital can easily bypass. While the U.S. maintains a clear lead in high-end chips, we are hitting a wall on how we manage the mundane essentials like electricity and water. In the geopolitical race, the US has the chips, but China has the centralized command over infrastructure. Our democratic model requires transparency and public buy-in to function. If U.S. companies keep relying on secret deals to push through expensive, overbuilt infrastructure, they risk a total collapse of community trust.

The Roadmap to Production AI

When AI Agents Get Their Own Social Network

Ben Lorica edits the Gradient Flow newsletter and hosts the Data Exchange podcast. He helps organize the AI Conference, the AI Agent Conference, the Applied AI Summit, 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-Native Security Playbook: Six Essential Shifts

As we expand from AI-assisted tools to AI-native operations, the security landscape is undergoing a structural transformation. Those building, scaling, and investing in generative AI applications, are starting to see a shift from static models to autonomous agents with the authority to interact directly with enterprise systems. This evolution brings a new set of challenges that extend beyond traditional cybersecurity, touching on the integrity of data, identity, and corporate governance. After reading emerging threat intelligence reports and picking the brains of people on the front lines of cybersecurity, I’ve compiled this short guide to the essential shifts and defensive measures teams must adopt as we enter this next AI chapter.

Subscribe now

I. Autonomous Systems and Identity

Agentic Autonomy and the Non-Human Identity (NHI) Crisis
A key architectural shift in AI will be the move toward “agentic” systems — autonomous software entities capable of planning and executing multi-step tasks across enterprise environments. These agents require privileged access to APIs and databases to function, effectively becoming a new category of “insider.” This shift coincides with a massive proliferation of Non-Human Identities (NHIs): machine and AI identities are projected to outnumber human employees by a ratio of 80 to 1. The convergence of these trends creates a high-stakes vulnerability: “goal hijacking.” Adversaries can use specialized inputs to override an agent’s original logic, triggering unauthorized actions like fraudulent financial transfers or data exfiltration at machine speed.

In the past, digital security was like guarding the “front gate” of a company’s network. Today, that boundary has shifted: security now depends on verifying the digital “ID” of every individual and AI program. In this environment, if a firm cannot distinguish its own AI agents from impostors, the Zero Trust strategy — which relies on proving one’s identity for every single task — loses its ability to protect the business.

AI teams must integrate all AI assets into existing Identity and Access Management (IAM) frameworks, treating every agent as a distinct NHI with its own credentials and audit logs. They should deploy automated discovery tools to maintain a real-time inventory of all active agents and their associated access rights. They should also monitor agent behavior in real time and enforce “circuit breakers” that require human intervention for high-stakes operations, such as fund transfers or structural changes to production infrastructure.

The challenge is compounded by the ephemeral nature of these entities. In a mature agentic ecosystem, ‘swarms’ of agents may be instantiated to perform a single task and then decommissioned within minutes. Traditional security architectures that rely on periodic scans — even those occurring every few hours — will fail to detect these identities entirely. Security teams must move toward event-based, real-time monitoring that captures the ‘birth’ and ‘death’ of an agent to ensure that every action can be traced back to a specific intent, even after the agent has vanished.

Effective management requires a ‘universal identity’ framework. Because a single agent may hold disparate credentials across cloud providers, databases, and SaaS platforms, firms must rationalize these accounts into a single authoritative record. Without this consolidation, security teams cannot calculate an agent’s cumulative access levels or execute a global ‘kill switch’ if the entity is compromised.

II. Model Integrity and Adversarial Manipulation

Adversarial Prompting and Knowledge Base Corruption
Adversaries are shifting focus from attacking the infrastructure to attacking the “logic” and “data” of the model itself. This involves “prompt injection,” where malicious instructions are hidden within data (such as emails or support tickets) that an AI system is designed to summarize or act upon. Furthermore, as Retrieval-Augmented Generation (RAG) becomes a standard for enterprise AI, “data poisoning” has emerged as a critical threat. This involves injecting misleading information into the knowledge bases that feed AI systems to create “backdoors” or cause the model to provide dangerously inaccurate advice. In sectors like finance or healthcare, where model outputs drive high-value decisions, this corruption can lead to systemic failures that are difficult to detect through traditional perimeter defenses.

Beyond technical injections, adversaries are finding success in social engineering the agents themselves. Because these systems are designed to be helpful and responsive, they can be ‘bullied’ or pressured through prompts that simulate high-stakes urgency — such as an attacker claiming to be a board member requiring immediate access to prevent a system failure. Unlike humans, who may rely on intuition to flag suspicious behavior, an agent may prioritize its ‘helpfulness’ directive over security protocols unless strict behavioral constraints are hard-coded into its logic.

Teams should design AI pipelines to treat all retrieved or user-provided content as untrusted data. Beyond simple prompt engineering, developers should implement technical filters (and guardrails) that strip command-like directives from data before it reaches the model. For RAG systems, it is essential to establish an auditable chain of custody for all datasets and maintain strict versioning of knowledge bases. This allows for a rapid “rollback” to a verified clean state if corruption is identified.

III. The AI-Accelerated Development Lifecycle

The Compressed Exploit Window and Supply Chain Risks
The use of generative AI in software development is significantly increasing the velocity of code production, but it is also introducing new vulnerabilities. Developers often accept AI-generated code without a deep understanding of its logic, risking the inclusion of “hallucinated” dependencies — references to non-existent software libraries that attackers can later create and populate with malware. Simultaneously, AI is enabling attackers to reverse-engineer security patches and develop working exploits in a matter of hours. This “compressed exploit window” means that traditional, periodic patching schedules are no longer sufficient to protect AI application stacks, which rely on rapidly evolving components like vector databases and model gateways that still lack the mature patching ecosystems of legacy software.

A critical vulnerability in AI-assisted development is the ‘permission gap.’ Agents typically operate using the credentials of the developer, yet they lack the human’s contextual understanding of the impact of their actions. An agent tasked with ‘optimizing code’ may lack the judgment to realize that a specific command could be destructive to production infrastructure. To mitigate this, developers should embed ‘policy hooks’ within the development environment — automated constraints that prevent agents from executing high-risk commands regardless of the user’s authorization level.

To maintain security at high development speeds, teams must institute mandatory, human-led code reviews for all AI-generated changes. AI-assisted development tools should be configured to prioritize security-hardened libraries and patterns. Additionally, teams should utilize a “Software Bill of Materials” (SBOM) — a formal record containing the details and supply chain relationships of all components used in a build — to continuously track and verify every dependency, ensuring no malicious packages have been introduced during the generation process.

IV. Data Exposure and the Shadow AI Perimeter

The Permeable Perimeter and the Blast Radius

The traditional corporate perimeter is becoming increasingly permeable due to “Shadow AI” — the unauthorized use of unvetted platforms to process proprietary data. This is no longer merely a human behavioral issue: it has evolved into a “transitive risk” where authorized primary agents autonomously invoke unauthorized third-party models or “shadow” APIs to resolve sub-tasks. These create invisible leakage pathways where sensitive intellectual property is passed to unvetted environments without any human interaction.

This external exposure is compounded by internal “data sprawl.” Because AI agents can search, summarize, and traverse documents orders of magnitude faster than humans, any misconfiguration in an agent’s permissions creates a massive “blast radius.” The scale of this risk is quantified by the permission gap: while human employees are typically over-permissioned by 70%, AI identities often see rates as high as 90%. While a human might never discover their latent access to a sensitive database, an autonomous agent possesses the computational capacity to systematically explore every “nook and cranny” of its environment. What was once “security by obscurity” is now a liability, as a minor configuration error can be turned into a rapid, comprehensive data exfiltration event at machine speed.

To mitigate these risks, organizations must provide sanctioned, high-performance AI alternatives to discourage the use of unvetted tools. Simultaneously, they should adopt a “minimum necessary data” posture — indexing only essential information for AI retrieval and implementing row-level access controls. By ensuring that agents only “see” data that the requesting user is specifically authorized to view, firms can effectively shrink the potential blast radius of a compromised or misconfigured identity.

V. Verification and the Authentication Crisis

Synthetic Deception and the Failure of Perceptual Trust

Deepfake technology is approaching a level of sophistication where AI-generated audio and video are virtually indistinguishable from reality. This undermines the bedrock of enterprise trust: attackers can use “CEO doppelgangers” to authorize fraudulent transactions or trick IT help desks into resetting credentials via realistic video calls. When perceptual cues like a person’s voice or face can no longer serve as proof of identity, traditional social engineering defenses and biometric verification become obsolete.

To counter this, organizations must move toward phishing-resistant multi-factor authentication (MFA) using hardware security keys for all human users. High-sensitivity requests should also require “out-of-band” verification—confirmation through a separate, trusted channel—regardless of how legitimate the requester appears on a screen.

The Agent Authentication Gap

While MFA secures the human element, it is notoriously difficult to enforce on non-human identities. In the race to deploy agentic systems, many developers have bypassed security protocols entirely, opting for hardcoded credentials or long-lived tokens embedded directly into agent logic. This creates a massive, static vulnerability.

For agents, the equivalent of MFA is not a hardware key, but a combination of Privileged Access Management (PAM) and Just-in-Time (JIT) access. Rather than holding permanent credentials, agents should be granted ephemeral, “right-sized” permissions that expire immediately after a task is completed. Furthermore, teams must implement “behavioral baselining” to detect “evil twin” scenarios — where a malicious agent mimics the communication patterns of a trusted system. By monitoring the specific “cadence” of an agent’s API calls, defenders can identify subtle anomalies that suggest a legitimate identity has been compromised or replaced.

VI. Operational Resilience and Governance

Defensive AI and Quantifiable Resilience Metrics
As security alerts outpace human capacity, organizations are deploying defensive AI to triage and remediate incidents. This autonomy, however, creates a governance vacuum: with the vast majority of AI systems now capable of modifying identities without human oversight, traditional ‘aspirational’ policies have become obsolete. In their place, we expect boards to start demanding quantifiable ‘resilience KPIs.’ Chief among these is ‘time to revocation’ — the speed at which a compromised agent’s credentials can be neutralized across the entire infrastructure — alongside metrics for the rapid restoration of corrupted data indexes.

If you decide to deploy defensive AI agents, start with “recommendation-only” modes before granting autonomous authority. Every action taken by a defensive agent must be logged in a structured format to allow for rapid human validation. To satisfy governance requirements, AI teams should maintain a living inventory of all models, prompts, and datasets, and conduct regular “tabletop” exercises that simulate AI-specific failure scenarios to validate technical controls and organizational response.

Ultimately, the transition to AI-native operations is a necessary inflection point for corporate security. For years, organizations have tolerated 'identity debt' — unresolved vulnerabilities in how they manage human and machine access. The arrival of autonomous agents, with their unprecedented speed and scale, renders that debt unmanageable. The shift to agentic systems is not merely a new threat surface; it is the catalyst that will finally force enterprises to master identity security as the primary defense of the modern era.

Submit A Talk

Ben Lorica edits the Gradient Flow newsletter and hosts the Data Exchange podcast. He helps organize the AI Conference, the AI Agent Conference, the Applied AI Summit, 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

AI Reliability Patterns That Generalize Beyond Medicine

The gap between pilot projects and production deployments has emerged as a defining challenge for enterprise AI teams. Recent surveys indicate that only a small percentage of generative AI initiatives reach full production, with most stalling due to brittle workflows and integration failures. At last year’s AI Conference, several colleagues independently told me that reliability — not raw performance — has become their primary concern. This rush-to-market mentality, with 56% of technical leaders admitting they prioritize speed over safety, results in systems prone to unpredictable and hard-to-diagnose failures.

The emphasis on reliability stems from a practical reality: in real-world AI applications, predictability often matters more than peak accuracy. When Harvard researchers tested a medical AI with the same clinical case but different personas, the system recommended growth hormone therapy when “acting as a physician” but denied identical treatment when “acting as an insurance representative.” Such non-deterministic behavior makes systems unusable regardless of benchmark scores, creating compliance nightmares and destroying stakeholder trust. My interest in AI reliability brought me to healthcare, the domain where unreliable systems carry the highest possible stakes. The hard-won lessons from medical AI teams provide a roadmap that translates powerfully to any industry serious about building dependable systems.

How Medical AI Systems Break Down

The challenges in medical AI reliability are multifaceted, spanning model behavior, data quality, and human-computer interaction. Hallucinations represent perhaps the most dangerous category: generative models produce confident but entirely fabricated information. A recent case documented in the Annals of Internal Medicine involved a chatbot recommending bromide — a toxic chemical — as a table salt substitute. The user followed the advice and required hospitalization for severe poisoning. What makes hallucinations particularly insidious is their plausibility; fabricated lab values or treatment recommendations often appear reasonable to non-specialists, allowing “corrosive hallucinations” to survive routine checks.

Output inconsistency compounds these risks. Research testing large language models on orthopedic treatment guidelines found that the same AI system produced contradictory medical recommendations depending solely on how the question was framed. When given identical clinical scenarios through different prompting approaches, one model provided varying levels of treatment endorsement for the same osteoarthritis interventions, with consistency rates fluctuating dramatically based on the input style alone. This prompt-dependent reasoning reveals a fundamental reliability flaw: the system optimizes for perceived question expectations rather than consistent clinical logic. The specialized medical AI CaBot demonstrated similar brittleness, performing expertly on structured clinical cases but hallucinating fabricated vital signs when presented with the same patient history in narrative format. This fragility to input formatting — where minor prompt changes collapse performance — mirrors challenges teams face across domains when deploying models trained on curated benchmarks into messy production environments.

The human-system interaction risks deserve particular attention for their applicability beyond healthcare. A mammography trial found that radiologists using AI assistance correctly identified only half the malignancies their unaided colleagues caught (50% versus 68%). Clinicians excessively deferred to the tool, treating the absence of an AI alert as confirmation of a clean scan. This automation bias — where human operators over-trust algorithmic outputs even when incorrect — represents a systemic failure mode that affects any domain where AI assists expert decision-making. Another emerging concern is cognitive de-skilling: gastroenterologists who regularly used an AI polyp detection tool became significantly worse at the task when performing it without assistance. This skill atrophy reduces overall system resilience, creating brittle human-AI combinations that perform worse than either component alone.

A Practical Playbook for Medical AI Reliability

Just as the challenges are well-defined, so too are the strategies for mitigating them. For generative AI, one of the most effective techniques is Knowledge Grounding and Evidence Integration. By implementing Retrieval-Augmented Generation (RAG), systems can be guided to base their responses on information retrieved from vetted sources like medical knowledge bases, clinical guidelines, and peer-reviewed literature. This approach reduces hallucinations and, when combined with Structured Citation and Source Verification, allows clinicians to independently validate the model’s reasoning chain, building essential trust and transparency.

A second crucial set of tools falls under Uncertainty Management and Selective Deployment. A reliable system must know its own limits. The Therabot clinical trial illustrates why such selective abstention matters: despite careful fine-tuning on curated dialogues, human clinicians still needed to manually review all AI-generated messages to catch instances of false medical advice. Techniques like Selective Prediction and Abstention configure a model to refuse to answer low-confidence or out-of-scope queries, automatically routing them to a human expert instead. This ensures that the system fails gracefully rather than providing a potentially dangerous guess. Well-calibrated confidence scores enable systems to gate high-stakes actions, preventing autonomous behavior when uncertainty is high. This principle is broadly applicable: any enterprise system, whether in finance, law, or manufacturing, benefits from an AI that knows when to ask for help.

Finally, effective reliability requires designing robust Human-AI Collaboration Frameworks. Instead of replacing human experts, AI should be integrated into Structured Human-in-the-Loop Workflows. The AI can serve as a “first opinion” tool to surface possibilities, a “second opinion” to validate a diagnosis, or a “safety net” to flag potential omissions. Each pattern maintains appropriate human oversight while leveraging the AI’s strengths. Furthermore, simple interventions like Prompting Protocols and Training — teaching healthcare providers how to formulate queries to elicit differential diagnoses rather than single answers — can measurably improve output quality and reduce the impact of prompt sensitivity.

Broader Lessons for Building Dependable AI

While these examples are drawn from the high-stakes world of medicine, the underlying principles apply directly to any enterprise AI application. The medical AI experience reveals that reliability challenges stem less from model architecture limitations than from deployment patterns and system design choices. Hallucinations, output inconsistency, automation bias, and cognitive de-skilling affect any application where generative models provide decision support to human experts. Similarly, the remediation techniques — knowledge grounding, uncertainty-aware abstention, and structured collaboration patterns — transfer directly to other domains. Teams building financial analysis tools, legal document systems, or software engineering assistants face the same fundamental tension between model capability and deployment reliability.

The evolution from pilot to production requires deliberately engineering for predictable behavior rather than optimizing for peak performance on curated benchmarks. This connects to the broader challenge of multi-agent systems: when systems fail, practitioners need structured frameworks for identifying whether failures stem from input distribution shifts, poor calibration, inadequate validation, or inappropriate human-system interaction patterns. By treating reliability as a first-class design concern — implementing layered defenses, monitoring for drift, and carefully structuring human oversight — teams can build generative AI applications that organizations will actually trust in production. The 95% pilot failure rate suggests most teams are still learning these lessons.

From the Archives: Related Reading

• Agent workflows: stop guessing, start measuring

• Are Your AI Agents Flying Blind in Production?

• [2024 Report] Generative AI’s Impact on Healthcare

Tool Recommendations

When reading about AI coding tools, the names that often get mentioned are Claude Code, Cursor, and Google Antigravity. I’d like to put forth another option that I’ve come to enjoy using: the combination of OpenCode and OpenRouter. While I’m not really an early adopter and put off trying the OpenCode Desktop App for a while, I finally jumped in several weeks ago and have to say I’ve really enjoyed using it. This combination has really hit the sweet spot for me — when you pair OpenCode with OpenRouter’s easy access to all the leading models for coding, it becomes an incredible toolset for your projects or for developing tutorials and courses.

• Off the Scales: The Inside Story of Ozempic and the Race to Cure Obesity. I found this to be a lean, rigorous account of the GLP-1 revolution, tracing the path from fundamental laboratory research to a global pharmaceutical phenomenon. It offers a clear-eyed look into the drugs currently reshaping the healthcare and food industries.

• Moderation: A Novel. A sharp, unsentimental look at the “digital sanitation” required to sustain virtual reality and AI ecosystems. It moves beyond the hype of immersive platforms to examine the human labor and systemic risks that founders and investors often overlook.

• True Nature: The Pilgrimage of Peter Matthiessen. This cradle-to-grave bio is a clear-eyed profile of the only writer to secure National Book Awards for both fiction and nonfiction. It traces his trajectory from CIA-linked literary circles in Paris to the front lines of environmentalism, detailing both his brilliance and his significant personal failings. It’s a long read, but well worth it.

Ben Lorica edits the Gradient Flow newsletter and hosts the Data Exchange podcast. He helps organize the AI Conference, the AI Agent Conference, the Applied AI Summit, 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’s Emerging in Financial AI: From Foundation Models to Compliance-as-Code

While the public discourse remains fixated on Artificial General Intelligence, the more immediate and consequential story is the diffusion of AI into specialized enterprise domains. Having spent time as a quant within the hedge fund industry, I have long viewed financial services as the primary bellwether for how emerging technologies transition from research labs to production environments. The sector’s unique combination of high-frequency data, rigorous regulatory constraints, and clear economic incentives makes it an ideal laboratory for stress-testing new technologies. While I track the evolution of foundation models closely, my interest is primarily pragmatic: I look for how breakthroughs in relational modeling, reinforced reasoning, and multimodal integration can be harnessed to solve specific, high-stakes problems within enterprises.

Foundational Model Architectures (The New Capabilities)

Time-Series and Relational Modeling

While Time Series Foundation Models (TSFMs) are establishing new benchmarks for forecasting and anomaly detection, a more recent shift lies in Relational Foundation Models (RFMs). By employing Graph Transformers, these architectures map entities as nodes and interactions as edges, allowing the model to “borrow strength” from connected signals — such as supply chain links or customer-product hierarchies. This approach enables the system to capture how idiosyncratic events propagate through a business network, effectively bypassing the need for manual feature engineering in complex relational datasets. In a recent conversation, we even speculated on whether this ability to model interdependencies could offer a distinct edge in quantitative trading.

Multimodal Integration

Financial analysis will transition from text-heavy Large Language Models (LLMs) to Multimodal Financial Foundation Models (MFFMs) capable of ingesting interleaved data streams. Rather than segregating data into distinct pipelines, these systems process audio from earnings calls, video from policy conferences, tabular financial statements, and market tick data within a unified embedding space. The objective is to replicate the workflow of a human analyst, who simultaneously synthesizes management tone, quantitative metrics, and price action into a single coherent thesis.

Reinforced Chain-of-Thought

To handle complex problems and tasks, some teams are starting to train models rather than just prompt them more cleverly. Using reinforcement learning methods such as GRPO, they teach models to lay out their reasoning step by step when answering financial questions. Because this behavior is built in during training, the system can solve multi-step problems more accurately without depending on a human to provide detailed guidance every time.

The Shift to Small Language Models (SLMs)

The prevailing assumption that superior performance necessitates massive parameter counts is being challenged by a focus on operational latency and data sovereignty. For real-time applications, such as fraud detection or mobile interfaces, the inference costs of frontier models (often exceeding 70 billion parameters) can be prohibitive. The trajectory for 2026 favors Small Language Models — typically under 7 billion parameters — that achieve frontier-level performance on narrow, domain-specific tasks. This architecture will allow financial institutions to deploy sophisticated reasoning on commodity hardware within air-gapped servers, ensuring sensitive data never leaves the premises.

Autonomous Market Microstructure

A quiet transformation is occurring in the “last mile” of finance: trade execution. Research indicates that deep learning models can effectively interpret real-time buy and sell orders to forecast liquidity and future price movements with superior accuracy. This development lays the groundwork for autonomous agents that go beyond price prediction to actively negotiate trades, adapting execution strategies in real-time to minimize slippage and costs in volatile market environments.

Deployment Patterns (How It’s Being Used)

Multi-Agent Workflows

The paradigm is shifting from single-prompt problem solving to the optimization and orchestration of specialized agent “crews.” In these systems, distinct agents assume roles such as “Planner,” “Coder,” “Risk Officer,” or “Auditor,” collaborating to execute complex workflows. These agents leverage standardized protocols, such as the Model Context Protocol (MCP), to utilize external tools and communicate. Tool Agents manage search and code execution, while Financial Service Agents handle domain-specific tasks like credit scoring and compliance, creating a modular and resilient operational structure.

Hybrid Quant Architectures

Rather than displacing incumbent quantitative infrastructure, modern AI is increasingly integrated as a reasoning and interface layer on top of established engines. In these hybrid stacks, LLMs handle semantic tasks — summarizing research, proposing signals, and explaining portfolio composition — while TSFMs and RFMs generate forecasts. However, critical functions such as allocation, risk management, and execution remain the domain of traditional optimizers and models. LLMs are often utilized “offline” to extract features from unstructured text, which are then fed into robust, lightweight classical models (such as XGBoost) for final prediction.

Open-Source Alpha Generation (WallStreetBets 🤜🤛 AI)

A growing body of research focuses on the democratization of systematic investment strategies using open-weights models and public data. These pipelines typically ingest unstructured content — news, social media, and video transcripts — to extract signals. These signals are subsequently processed by classical models and portfolio optimizers. This trend suggests that the barrier to entry for sophisticated, data-driven investing will lower even more, enabling smaller institutions and retail investors to construct alpha-generating strategies previously reserved for well-capitalized firms.

Safety, Governance & Production Infrastructure (Making It Real)

“White Box” Verification

To mitigate the risk of hallucination, institutions are adopting “White Box” architectures that position LLMs as critics and auditors. Systems utilizing frameworks like FISCAL and FACTS employ agents to validate numerical claims against primary financial documents and summarize complex tabular data. By grounding outputs in structured data and implementing agentic workflows for claim-checking, these architectures prioritize explainability and factual accuracy over pure generative capability.

Privacy-Preserving Deployment

With strict regulatory constraints on data sharing, the focus is turning toward adapting LLMs for financial tasks without exposing sensitive information to third-party providers. Techniques such as context-masked meta-prompting — which sanitizes inputs prior to inference — and the generation of offline, reusable prompt templates are becoming standard. Furthermore, governance mechanisms — including logging, rule-based overlays, and unlearning protocols — are being treated as primary design requirements rather than afterthoughts.

Synthetic Data Infrastructure

Synthetic data is evolving from a niche research topic into a core infrastructure tool. Generative models are now used to create multimodal datasets that mimic proprietary distributions — preserving the statistical properties of sensitive data without exposing underlying records. In market risk, these models generate realistic but counterfactual return paths, including synthetic “crash” scenarios. This allows for robust stress testing and the simulation of limit order books, providing a safe environment for model training and validation.

Continuous Compliance

Regulatory frameworks like the EU AI Act are driving a transition from periodic model validation to “compliance-as-code.” In 2026, compliance is expected to become a continuous architectural process. This involves real-time lineage tracking to document data provenance for every inference, alongside automated benchmarking suites (such as FLAME) that stress-test models against adversarial scenarios and regime shifts. Systems will be required to generate automated evidence of adherence, managing model drift and fairness violations dynamically as they emerge.

Quick Takes

1. The Humanoid Takeover: Key Takeaways from CES 2026

2. The Great Relaxation: Analyzing the New H200 Chip Export Policies

Self-Correcting Agent: Closing the Loop with Formal Verification

This recent example from the world of mathematics caught my attention as an example of a “verified” AI pipeline. The workflow shows how to turn an ambiguous goal into a checked result: an LLM proposes a solution, a formal verifier (proof assistant) checks it, and the loop repeats until it passes. Once the core artifact is verified, you can reliably generate multiple explanations — technical, narrative, or research-style — grounded in the same source.

Ben Lorica edits the Gradient Flow newsletter and hosts the Data Exchange podcast. He helps organize the AI Conference, the AI Agent Conference, the Applied AI Summit, 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

Agent Optimization: From Prompt Whispering to Platform Engineering

Agent optimization is the work of making an agent workflow dependable — despite long tool chains, multiple roles, and the inherent variability of large language models. In day-to-day engineering terms, it is closer to debugging a complex system than “making the model smarter”: you are tuning roles, prompts, routing, memory, tool use, and verification so the workflow stops failing in repeatable ways.

The problem has become important because many teams see the same pattern: a compound system looks impressive in a controlled demo, then breaks under real-world inputs and operational constraints. The root cause is often not raw model capability, but workflow issues — role drift, context loss, weak verification, and coordination failures — that only show up when you run the full loop repeatedly.

Subscribe now

Without the specialized tools emerging in this space, the default playbook is manual and hard to scale: engineers read traces by hand, add logs, tweak prompts, patch edge cases with heuristics, and rely on coarse pass/fail dashboards that discard most of the diagnostic signal in the execution trace. Traditional gradient-based training doesn’t directly apply because the workflow is non-differentiable (it includes API calls, tools, and conditional logic), and many teams only have API access to models — so even if fine-tuning would help, it may not be available.

Furthermore, as the number of agents and tools grows, the combinatorial complexity of the system makes manual debugging unscalable. A single change in one agent’s prompt can have unpredictable downstream effects on the entire collective, leading to a “guessing game” that consumes vast engineering resources without guaranteeing improvement.

The New Tools of Agentic Engineering

A practical toolchain is emerging that makes the loop more systematic: instrument the workflow, diagnose failures, evaluate variants, and then use search or automated refinement to improve prompts and architecture — while adding guardrails so the optimizer can’t “cheat.”

System Observability (The Flight Recorder). Optimization starts with complete, queryable traces: prompts, tool calls, intermediate outputs, routing decisions, and state. In one MAST-based case study, teams used trace tooling (agentdash) to annotate runs and generate failure histograms, turning debugging from anecdote into measurable error categories.

Diagnostic Failure Taxonomies (The “Why” Signal). Instead of “accuracy dropped,” teams increasingly want “verification failed” or “agents ignored key context.” MAST is one example: it organizes failures into system design issues, inter-agent misalignment, and task verification problems. The practical benefit is prioritization — fix the dominant failure class first, rather than iterating blindly.

Targeted Evaluation (The North Star). ​​Optimization is only as good as the metric it targets. This layer moves beyond public benchmarks to create custom “ground truth” datasets that mirror specific business logic. Using platforms like Prompt Flow, teams build evaluation sets alongside the application. For complex qualitative traits like “clarity,” teams use Model-Graded Scoring, where a more capable model acts as a judge. To handle the inherent unpredictability of AI, some teams now use Tournament Selection, where variants compete head-to-head and are ranked via Elo ratings, providing a more robust measure of effectiveness than a simple pass/fail score.

Textual Gradients (The Feedback Mechanism). Because agent workflows coordinate discrete tools and APIs, they cannot be improved using the standard math of neural networks. Frameworks like TextGrad solve this by using “textual gradients” — detailed natural language critiques that explain exactly why a specific step failed. This feedback is propagated backward through the system’s logic to automatically update prompts or code, allowing the system to learn from its mistakes using language rather than numerical scores.

Automated Refinement (The Tuner). Instead of hand-editing prompts, teams are adopting algorithmic optimizers. DSPy replaces static strings with optimizable “signatures,” using tools like MIPROv2 and COPRO to search for the best combination of instructions and few-shot examples. AdalFlow pushes a related idea into a more pipeline-centric library: prompts and few-shot demonstrations become parameters that can be refined via an “AutoDiff”-style loop driven by performance metrics.

Structural Evolution (The Architect). Multi-agent design is difficult because the space of possible connections and orchestration patterns grows exponentially as agents are added. Frameworks like OpenEvolve and GEPA (Genetic-Pareto Evolution) address this by treating system architecture as a search problem. They mutate “code knobs” — such as agent roles, communication topology, and prompts — and evaluate the variants using detailed diagnostic feedback on why they failed. This process often uncovers patterns humans miss, such as splitting a failing generalist into specialists or using “negative constraints” — explicit “do not” instructions (like “do not plan”) — to keep agents from overstepping their assigned roles.

Multi-Stage Gatekeeping (The Verifier). Reliability improvements often come from separating “generate” from “verify,” and layering checks. One pattern is hybrid verification: run cheap deterministic checks (e.g., syntax/AST parsing) before invoking slower, costlier model-based review. Another is a dedicated verifier role (e.g., SimpleVerifier) that acts as a gatekeeper rather than a stylistic reviewer.

Governance and Safety (The Guardrails). To prevent “reward hacking” — where an AI finds a shortcut to a high score without actually solving the task — teams must enforce strict boundaries. This involves using surgical edits (or “diffs”) that restrict the AI to changing specific pieces of logic rather than rewriting entire files; this prevents the system from accidentally deleting its own safety checks to “cheat” the evaluation. Additionally, a Memory Module acts as a permanent record of the “best-known” version of the system, ensuring that as the AI experiments with new designs, it never loses progress or reverts to a lower-performing state.

The Practical Hurdles of Optimization

Despite the rapid advancement of these tools, several significant hurdles remain for AI teams.

• The Risk of Reward Hacking: Automated optimization systems are highly efficient at finding shortcuts. In one documented case, an evolutionary algorithm “improved” its score by simply deleting the agent responsible for reporting failures. Without strict guardrails, systems may optimize for the metric rather than the actual business objective.

• Evaluator Fragility and Noise: If the initial evaluation metrics are poorly defined or the test data is not diverse enough, the refinement process will optimize for the wrong outcomes. An “evals-first” approach is difficult to operationalize when the “ground truth” for a task is subjective or constantly shifting.

• Judge Bias and Inconsistency: Relying on an LLM to evaluate the performance of other agents introduces potential biases. A “judge” model might reward linguistic fluency over functional correctness or exhibit a preference for its own coding style, necessitating a skeptical approach to purely automated scoring.

• Computational Intensity and Latency: Generating and testing dozens of code variants is resource-heavy. For teams with strict cost or latency constraints, the iterative nature of evolutionary search can be prohibitive, requiring careful use of “improvement thresholds” to stop the loop when gains become marginal.

• Overfitting and Generalization: A prompt or topology that performs exceptionally well on a specific evaluation set may fail to generalize to real-world novelty. Ensuring that an optimized agent remains robust against “data drift” is an ongoing challenge that requires diverse, adversarial test sets.

• Tooling Fragmentation and the “Integration Tax”: An engineering team must manually stitch together best-of-breed (open source) solutions for observability from one library, failure taxonomies from another, and optimization engines from a third. This fragmentation creates a significant “integration tax,” where developers spend more time plumbing data between tools than actually refining agent behavior. For optimization to become a standard enterprise discipline, these capabilities must coalesce into integrated, end-to-end platforms that manage the entire loop within a single environment. Proprietary platforms like Plurai are headed in this direction.

A Discipline, Not a Bag of Tricks

Teams are moving from a model-centric era to a system-centric one. In the past, performance gains were achieved by upgrading to a larger Foundation Model. Today, as demonstrated by case studies using the MAST framework, teams can achieve a 50% or greater improvement in accuracy simply by rewiring an agent graph and adding stateful memory — without upgrading the underlying model. This shift transforms agent optimization from a “guessing game” into a scalable, interpretable engineering process.

This evolution fits into a broader architectural trend. Just as the PARK stack (PyTorch, AI Frontier Models, Ray, Kubernetes) has standardized the compute substrate, and Multimodal Lakehouses are beginning to consolidate the data layer, agent optimization is becoming the refinement substrate. The next major milestone for the ecosystem will be the arrival of open source optimization frameworks that integrate natively with these other layers — allowing an optimizer to scale across a Ray cluster or query a multimodal lakehouse without bespoke glue code.

For CTOs and founders, the competitive advantage is no longer the model they use, but the speed and rigor of their optimization loop. The teams that ship reliable agents will look less like prompt whisperers and more like disciplined platform teams — treating agent behavior as something you can measure, diagnose, and iteratively harden.

Subscribe now

Smart Tool Recommendations

Speechify. My secret weapon for clearing a “to-read” list. Speechify turns web pages, newsletters, and PDFs into high-quality audio that actually sounds human. If you struggle to find time to sit and read, this is the solution.

Kasa Smart Plug. The most underrated tech in my house. Kasa Smart Plugs are cheap, reliable, and dead-simple to use. If you haven’t automated your lamps or sound system yet, this is your sign to start.

Ben Lorica edits the Gradient Flow newsletter and hosts the Data Exchange podcast. He helps organize the AI Conference, the AI Agent Conference, the Applied AI Summit, 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.