_{Guest contributor: Tomás Hernando Kofman is the CEO and co-founder of Not Diamond, the world’s largest vendor of intelligent model routing, powering auto-routing in OpenRouter and working with global Fortune 500 enterprises like SAP.}

TLDR: Intelligent model routing involves choosing the most cost-efficient model for a given prompt (regardless of your AI gateway). Routing is a challenging problem because you need to get it right over and over as models ship weekly, their pricing changes and harnesses evolve. Getting this right is critical as companies look to tame their AI budgets.

I’ve been speaking with a lot of Fortune 500 executives, and they are nervous.

Annual budgets and multi-year contract commits are getting consumed in months, individual developers are spending thousands of dollars per day on coding agents, and public markets are beginning to question whether it’s acceptable to pay $100 for an internal powerpoint presentation.

Marc Benioff, Aaron Levie, Uber, ServiceNow, and whoever spent half a billion dollars last month—they’re all on the rocket ship.

People are swinging between “what the fuck is happening” and “don’t make it stop”. Because if they stop, every competitor is going to lap them.

The good news, and the bad news, is that it is not going to stop. We have not even scratched the surface on how much money is going to get sucked into AI, nor how much is going to come back out.

Because the crazy thing is that most of the anxious F500 leaders I’m talking to are still only spending <$1000 a month per individual engineer on coding agents. Meanwhile, people like Pete Steinberger are personally spending $1M / month. Long-horizon tasks, sub-agents, parallelization, and expanding skill and adoption curves amongst developers means the ceiling is so much higher than most leaders even realize. And the better the models get, the more autonomous, the more we will spend.

Costs are not only going to grow in coding agents, which today represent more inference spend than every other AI category combined. The next two years will see non-coding use cases blow up as well.

A global cloud security company I’m working with is spending tens of millions of dollars per year on coding agents, but they’re spending even more on the AI-powered incident investigation product they make available to their customers. Other companies I’m working with are similarly seeing product spend eclipse coding agent spend.

Then think about what will happen when consumer agent usage fully unlocks. You won’t need to be a power user to spend a shit ton of money on AI. You will just need your AI agent to be a power user to spend a shit ton on AI.

In any domain, solving an overspending problem requires us to be able to understand where the cost is coming from and what the true value we’re receiving is relative to the market. We overspend only when the value we receive is less than what we could have gotten from an equivalent supplier.

In AI, the source of spend is inference across the various AI models available at any given time, and the value we receive is intelligence. To systematically solve the AI cost problem then, we need to be able to optimize the relationship between the models we’re invoking and the intelligence of their outputs. We need to be able to intelligently select the right model at the right time. This requires us to understand not only how much a token costs, but also how much intelligence itself costs.

A token is not a unit of value. It is no better a measure of value than word count is an effective measure of the value of a book. A token is a container for value, in which data is acted on through computational resources to produce intelligence. Intelligence is the unit of value; computation is the price. For the first time in history, we have a direct relationship between capital and intelligence. But what is intelligence, and how do you meter it? As the economic inputs and outputs of AI begin to explode beyond all human proportion, it is no longer enough to simply meter tokens.

Intelligent model routing predicts when to use which model on each input to optimally produce intelligence. It is not deterministic model routing, which sends tokens to one model or another based on hand-written rules. Intelligent model routing allows us to optimize the relationship between computation and intelligence.

Every engineer knows that we don’t need to use Opus 4.8 max for writing commit messages; these are one of the simplest tasks in any development workflow. Yet we personally default to doing so anyways because the marginal downside of the token cost is so low while the convenience and assurance of quality is so high. This continuous marginal waste, aggregated across the entire economy, amounts to billions of dollars poured every day into nothing more than the warming of circuits in data centers, and by extension, the planet.

The problem is that solving intelligent model routing is enormously difficult. How do you predict the intelligence of an output with less intelligence than it costs to produce it?

It’s not enough to just predict the right model at each turn, which is itself extremely challenging. Choosing the wrong weak model at the wrong time can lead to even more spending down the line as more powerful models have to go back and fix the mistakes. You also need to select the right reasoning effort, monitor the KV cache to avoid costs from switching models at the wrong time, and link these decisions together over long horizons with sparse rewards.

So while the premise of intelligent model routing is simple, I have never spoken with a team that has tried to build this internally and succeeded.

What’s worse is that it is not enough to solve this problem once: you have to re-solve it every week as new models are released, harnesses evolve, and pricing updates. And all the while, you need to maintain the quality of the frontier models without any degradation in user experience. Nobody likes buying the budget option. We want the best.

A few years ago, I made a bet that the future of AI would not be dominated by a single model. Since then, my company Not Diamond has been laser-focused on solving the problem of intelligent model routing, growing from our release of the first open-source model router to becoming the world’s largest provider of intelligent model routing, powering auto-routing in OpenRouter and working with global F500s like SAP. But we are still in our earliest days.

As AI eventually grows to becomes fully synonymous with the economy, I believe that intelligent model routing will become the control theory for the mediation of all economic value. Put simply, control theory is the discipline of algorithmically governing dynamical systems to achieve desired outputs. Similarly, I believe algorithmic model routing will give our society the ability to govern when, how, and why we use AI, promote a diverse market of providers, shift the locus of power from labs to consumers, and significantly reduce the ecological impact of AI while maximizing its effectiveness.

We are working with many of our customers on a soon-to-be released version of our product purpose-built for coding agent workloads, achieving significant cost reductions while maintaining Opus 4.8 max quality, as measured on benchmarks and real usage / developer productivity metrics. We have an early access program for select developers and F500 enterprises. If you want to work with me please email t5@notdiamond.ai.

Tomás Hernando Kofman is the CEO and co-founder of Not Diamond, an AI infrastructure company pioneering intelligent model routing. A mathematician and entrepreneur, he focuses on helping enterprises optimize AI performance, cost, and reliability in the rapidly evolving multi-model ecosystem.

_{Guest contributor: Jonah Lipsitt, PhD, MSc is a researcher at Forward Future. Before joining, Jonah spent nearly seven years at UCLA earning his PhD in Environmental Health Sciences, publishing 13 peer-reviewed papers across sustainability, public health, and geospatial applications. He's held research and engineering roles at Zipline and Deloitte.}

The Jar of Brown Water

Recently, Alexandria Ocasio-Cortez (AOC) held up a jar of brown, dirty water on the floor of Congress and said it was the drinking water of a community living next to a Meta data center in Georgia. She was pressing an EPA official about it during a May 2026 hearing, and the moment went viral. It did something I think we’ve badly needed: it forced a real conversation about what AI and data centers are doing to the environment, and to environmental health, the messier question of how the environment around us affects our bodies.

Her demonstration was not quite right, even if powerful.

Where AOC Misleads

Three things.

First, it isn’t true that the whole county’s water turned brown. The affected homes are likely a handful of properties near the construction site running on private wells, their own localized systems, drawing straight from the ground with no utility or treatment plant in between. The most-documented case is Beverly and Jeff Morris, whose house sits about 1,000 feet from Meta’s Stanton Springs campus on the Newton–Morgan county line. That’s a real hardship for those families. It is not the same as “the county’s drinking water is now brown.”

Second, there is nothing about running AI that turns water brown. Serving inference doesn’t produce sediment. The brown water is almost certainly from construction: clearing land, blasting, disturbing soil, dewatering, dropping the local water table. The tell is the timeline. The Morris family’s water trouble started back in 2018, when crews first began clearing the land, years before a single server switched on. Meta, for its part, commissioned its own groundwater study and concluded its work was unlikely to have affected the well, citing watershed and topography. But residents don’t buy it, and the EPA officially agreed to look into it. But notice what’s actually being argued over: the construction, not the AI or the data center operations.

Third, that construction point is bigger than data centers. Any large build (a warehouse, a highway interchange, a stadium) done close enough to a well without proper mitigation can foul someone’s groundwater. There is nothing uniquely AI about a backhoe.

So when AOC calls the jar “drinking water” destroyed by a data center, she’s compressing a construction story, a private-well story, and an AI story into a single image. They aren’t the same story.

Where She’s Right

Even if AOC’s theatrics are a bit problematic or misleading, was she right to drag this into Congress and the cultural spotlight? Yes. I think so.

We are far too late to this conversation about energy, carbon, materials, and the local cost of AI. That last one on local impacts leads to the asymmetry I can’t get past. When a town gets a new bridge, or even an Amazon warehouse, the people who live there get something back: they drive across the bridge, they get their packages a day sooner, some of them get jobs. A data center is different. Unless you happen to be a power user of AI who benefits from living a few milliseconds closer to the compute, the building next door is mostly imposition. (At least for now while AI is still nascent.)

Now imagine it’s your town. In a matter of months, in rural America, one of the largest buildings on the planet goes up next to your community.

What This Infrastructure Actually Costs

Humans aren’t going to stop building things, and building things has always cost the environment something. These projects devour concrete and steel. The brown-water phase AOC is pointing at is the construction phase: the loud, dusty, dirty part.

But the operational phase has its own bill. To run, data centers are packed with chips made from rare earths and other materials, much of it pulled out of the ground by mining that is brutal on the environment in its own right. Then, once it’s live, the data center burns energy to serve inference, and if that energy, or the cooling, throws off emissions, you can get a global cost (more warming from climate change) and a local one (worse air quality).

Data centers were about 1.5% of the world’s electricity in 2024, and the IEA expects that to roughly double by 2030. That is not the whole grid. But locally it can feel weird if the compute gets used in Palo Alto, and the infrastructure shows up in Georgia.

Memphis Is the Cleaner Example

If you want the sharper version of this story, don’t look at the brown jar in Georgia. Look at Memphis.

To power its Colossus supercomputer in South Memphis, Elon Musk’s xAI installed a fleet of gas turbines, essentially an on-site methane power plant. The trick was calling them “temporary,” which let them run without the air permits a normal power plant needs. By the spring of 2025, environmental groups counted as many as 35 turbines on the site, many operating with no permit at all. Then, in July 2025, the Shelby County Health Department gave xAI the clearance it wanted, a permit for 15 gas turbines, granted after the fact. By 2026 the NAACP, with the Southern Environmental Law Center and Earthjustice, had sued, arguing the broader power plant (dozens of unpermitted turbines across the Memphis area) is among the largest sources of smog-forming NOx in a region that already fails federal air standards.

So Why Pay the Cost?

So why build any of this?

Because a lot of people (including me) believe AI can be a net positive for humanity. That is AI’s environmental bargain: humanity and the planet absorb real costs now for a future benefit we can imagine but cannot yet prove. And I want to be honest about that: it is still a belief, with hints of proof, not a known outcome.

I don’t think humans, or Americans specifically, will change our individual behavior enough to head off the worst of climate change. The consumption we’d have to give up to bend the heating curves is, realistically, not happening. Much of the global impact is already locked in. We are headed for a hotter, more volatile climate, with all the uncertainty and strife that comes with it. A lot of people in AI believe this technology might be one of the only tools fast enough to claw some of that back: that even though AI emits carbon now, something ahead of us, maybe superintelligence, maybe just every climate scientist on earth working alongside a capable model, helps us reverse the trend faster than we otherwise could. In a way, we are accepting real environmental and community costs now in the hope that future technological progress helps reduce larger costs later. It’s like a vaccine. It hurts a little now, to be better protected later — given AI can help us both mitigate and adapt to future climate.

My favorite example of how AI can bring hope is fusion. When Lawrence Livermore’s National Ignition Facility finally hit fusion ignition (getting more energy out than the lasers put in), they leaned heavily on machine learning to design the implosion and dial in the lasers on the fuel. Although not Large Language Models (LLMs) the lab calls AI a key factor in getting there. 

In May 2026, an OpenAI reasoning model disproved a longstanding conjecture in discrete geometry, on a unit distance problem that Erdős first posed in 1946, turning up a new construction that a group of outside mathematicians then verified. By OpenAI's account, it was the first time a general-purpose model cracked a prominent open problem on its own. If AI can keep chipping away at problems like that, the upside to science and the rate of scientific improvement is enormous. If you believe AI can 10x, or 100x, or 1000x our productivity or scientific progress, then you might think we can get to some of these environmental solutions faster too. We just need to get these AI tools into the hands of our brightest minds. 

The other reason to pay the cost lies in the other costs we are already paying, that may be better cut first. If you take more than one international flight a year, that single trip almost certainly out-emits your entire year of ChatGPT or Claude use (for the average user): a transatlantic round trip runs on the order of a tonne of CO2 per passenger, while a heavy year of personal chatbot use is measured in kilograms. Aviation was about 2.5% of global energy-related CO2 in 2023, larger than every data center on earth combined. So is AI really the thing to give up? Would flying more help us reverse climate change? Yes, we absolutely need to reduce consumption in general if we are to stave off the worst impacts of climate change, but what goes first?

Who Bears the Brunt, and Who Benefits

So let’s give AI the benefit of the doubt. Say it’s worth building, even with the costs. And say the optimists are right that we can shrink those costs over time, with more efficient chips, cleaner mining, and hardware that lasts longer. (The chips really are improving fast: today’s AI hardware gets roughly 34–40% more efficient every year. The catch is that we keep buying so much more compute that total demand climbs anyway.) Fine, grant all of it.

The real question still stands, and it’s the one AOC is actually pointing at: who bears the worst of the cost, and who captures the benefit? While data centers bring tax revenue, economic deals, and jobs to rural areas, is it fair for Silicon Valley companies to reshape the local air, water, and ground in Georgia and Tennessee to achieve their ends? And when those same companies cut corners (skipping environmental review, taking carve-outs to move faster, running turbines without permits), of course it stops feeling fair.

We have to protect the most vulnerable people from the sharpest edges of this. We cannot let AI become an environmental justice problem. We cannot claim AI is for the good of humanity while being careless with the humans who need protection the most right now, in the present, before any of the promised future arrives.

To be clear - many leading AI companies are not ignoring these concerns. Data center construction and operations are getting cleaner and more efficient. Closed-loop water-cooling systems are possible. Frontier labs have publicly committed funding toward health, economic opportunity, AI resilience, and community programs – including paying for household utility costs around the datacenters they build. The labs have specifically funded outside research examining who benefits from AI and who may be harmed by it. Some of the largest studies on Universal Basic Income (UBI) have been funded by frontier labs. It is very hard to see around the corner of this massive technology, and independent research is likely key in understanding what lies ahead. If AI creates extraordinary value, some meaningful share of that value should flow back to the people and places absorbing its costs, and we need to better understand what those costs are.

The Race We’re Actually In

There’s a national-security version of the “go fast” argument that I actually buy: I would rather the world be shaped by AI developed in democratic societies than by AI developed under authoritarian systems. But if speed is the justification, let’s be honest about the race we’re actually in – one for not just AI and energy, but renewable energy. While we fight over gas turbines in Memphis, China is out-building the entire planet on energy: in recent years it has installed more new wind and solar than the rest of the world combined, several times what the U.S. manages in a year, and it already makes around 80% of the world’s solar panels and three-quarters of its batteries. China is still the biggest emitter on earth and still approves new coal, but its coal generation is now actually falling as clean power soaks up almost all of its new demand. They are quietly winning the cheap, clean power that AI will ultimately run on.

If we’re going to win, let’s win on the thing nobody has cornered yet: doing it right. Lead with renewables instead of diesel and methane turbines. Lead with closed-loop cooling and honest environmental review instead of waivers and carve-outs. Lead by taking care of the towns we build in and the people who get hit first. And lead with AI that’s genuinely meant to benefit all life, not just the sliver that can afford a subscription. A race to power the future on dirty energy, won over the backs of the communities hosting it, isn’t the kind of win that protects a way of life worth protecting.

The Solution Isn’t To End AI

The solution was never to stop AI development. The solution is to do and be better, faster, and that obligation falls on everyone holding a piece of this: the companies, the regulators, the local governments handing out the permits, and us. I believe AI will significantly benefit humanity, including those most vulnerable. But we have to be careful as we ‘go fast and break things’. It is not worth building a robot utopia if the cost is staying inside 24/7 because the air outside is too hot or gross to breathe. The physics of the climate and the environment are too large a system for superintelligence to fix overnight. And most importantly, AI isn’t the only thing to consider as stewards of the earth – many more of our behaviors and endeavors matter just as much.

On AOC: she was wrong to mislead. She was right to start the conversation. I hope the theatrics end up helping more than they hurt.

Jonah Lipsitt, PhD, MSc is a researcher at Forward Future. Before joining, Jonah spent nearly seven years at UCLA earning his PhD in Environmental Health Sciences, publishing 13 peer-reviewed papers across sustainability, public health, and geospatial applications. He's held research and engineering roles at Zipline and Deloitte.

Try Genspark free—sign up and get free credits today

_{Guest contributor: Ahmad M. Osman is an AI researcher and systems engineer specializing in infrastructure and hardware. He's building toward a frontier, infra-first AI lab in the West. Ahmad is also a GPU moderator and open-source AI advocate on r/LocalLLaMA, one of the largest communities for running AI models locally.}

I first posted an earlier version of this argument on X/Twitter, January 17, 2026. This version is expanded as of May 18, 2026, because the local model ecosystem, open-weight releases, tooling, and real-world risks around model-mediated cognition have moved fast enough that the argument deserves more context. 

Model names mentioned here will age. The core point will not. 

In short: You should own, borrow, rent, or otherwise get direct access to enough local compute to understand the systems that are increasingly mediating your thinking. 

The Wrong Bet 

People love arguing about AGI. Next year. Next decade. Already here. Never coming. Have the debates. 

But your personal compute strategy should not depend on resolving them. There is no guarantee we get AGI soon. There is no guarantee we get it at all. If we do, there is also no guarantee it runs on hardware you control, under rules you can inspect, with incentives aligned to you. 

That is the wrong bet though. 

The thing that matters right now is less cinematic: Language models are already inside the information layer of daily life. 

They help people search, write, summarize, code, negotiate, study, argue, date, break up, and make decisions. They are no longer "AI tools" in the narrow sense. They are becoming part of the cognitive supply chain.

When a system mediates what you read, what you write, what you remember, and what options you even notice, understanding that system stops being a hobby. It becomes literacy. Not "AI literacy" in the corporate training-video sense. Actual literacy. The ability to look at a machine-generated answer and feel, almost immediately: 

• This is fluent, but it may be wrong. 

• This is helpful, but it is steering. 

• This sounds neutral, but it has a policy stack, a prompt stack, a reward model, a product surface, and a business model behind it. 

The Fastest Way to Learn 

The fastest way to learn this is still brutally simple: Run the model yourself. 

Not because local models are magically pure. They are not. Not because cloud APIs are bad. They are extremely useful. And not because a 24 GB GPU turns you into a sovereign AI operator either. 

Run them because direct contact destroys mystique. Download weights. Load a model. Change the system prompt. Change temperature. Change context length. Play with different samplers / settings. Quantize it badly. Run the same prompt through three models. Watch one refuse, one flatter you, one hallucinate, and one confidently invent a library that has never existed. 

That first weekend teaches more than a year of "prompt engineering" content. You learn quickly that these systems are not oracles. They are conditional text machines trained into useful shapes; sometimes very useful shapes, sometimes dangerous ones. They can reason, retrieve, imitate, compress, persuade, and autocomplete with terrifying elegance. They can also make things up with perfect grammar. That combination is the whole point. 

The Local Model Ecosystem Is No Longer Exotic 

As of May 18, 2026, the local model ecosystem is good enough that running serious models on your own hardware is no longer an exotic research project.

OpenAI's gpt-oss release put gpt-oss-20b within 16 GB of memory and aimed gpt-oss-120b at a single 80 GB GPU. Qwen3.5 and Qwen3.6 pushed the Qwen line into newer open-weight multimodal and coding focused releases, including Qwen3.6-27B and Qwen3.6-35B-A3B, with official local-use paths through Transformers, llama.cpp, ExLlamaV3, MLX, SGLang, and vLLM. Google's Gemma 4 added an American Apache 2.0 open-model family spanning effective 2B and 4B edge variants, a 26B MoE model, and a 31B dense model, with support across tools like vLLM, llama.cpp, MLX, LM Studio, Unsloth, and SGLang. 

Those specific names will change. That is fine. The durable shift is that capable open-weight models, local inference engines, quantization tooling, and consumer or workstation GPUs now form a practical learning environment. 

Hardware 

A single 24 GB card is not frontier infrastructure. Two of them are not frontier infrastructure either. But they are enough to learn seriously, and a very useful ladder to understanding LLMs. 

If you are on a budget, I usually recommend 2x used RTX 3090s alongside ExLlamaV3. The GeForce RTX 3090 is Ampere, NVIDIA's 2nd-gen RTX architecture, with 24 GB of GDDR6X memory. Two 3090s give you 48 GB of total GPU memory to split across a multi-GPU-aware runtime; not a magic single 48 GB card. That distinction matters. ExLlamaV3 matters here because its EXL3 quantization path, cache quantization, and tensor/expert-parallel inference support are aimed directly at modern consumer GPU setups like this one. 

The RTX 5090 is the cleaner single-card consumer Blackwell option: 32 GB of GDDR7, fifth-generation Tensor Cores, fourth-generation RT Cores, PCIe Gen 5, and CUDA capability 12.0. It is simpler than a dual used-card setup like the 3090s, but the memory ceiling is still the memory ceiling, and you do not get to learn about parallelism and / or hack on it as much (not that it is a bad option). 

If you have the budget, the clean answer is the NVIDIA RTX PRO 6000 Blackwell Workstation Edition: 96 GB of GDDR7 ECC, 1.8 TB/s of memory bandwidth, PCIe Gen 5, CUDA 12.8, and MIG support for splitting the card into isolated GPU instances. 

Used servers, Macs with unified memory, cloud rentals, and shared lab machines can all be part of the same learning path. For the deeper expansion, read GPU Memory Math for LLMs (2026 Edition) for what fits in VRAM and the companion point that memory bandwidth determines speed. 

The point is not the brand. The point is having enough local memory, the right CUDA generation, and a runtime that can actually use the hardware without begging an API for permission every time your curiosity gets weird. Capacity determines fit; bandwidth helps determine how fast the work feels once it fits.

Cognitive Security 

This is where cognitive security starts. CogSec is not paranoia. It is not "the models are brainwashing everyone" conspiracy. It is what I would call "media literacy for generative systems". 

If you can steer a model, you can recognize when one is steering you. If you have never seen a system prompt, never touched a sampler, never watched temperature turn a boring assistant into a volatility machine, and never compared base model behavior to instruction-tuned behavior, then every polished chatbot feels a little too magical. 

That is dangerous. Not because every model is malicious. It's because a system does not need to be malicious to shape your choices. 

Hosted Models and the Invisible Stack 

Hosted models are wrapped in layers you usually do not see. This is not automatically sinister. Most of those layers exist because raw models are unreliable, unsafe, annoying, or commercially useless. But those layers matter.

OpenAI's public discussion of the Model Spec describes a chain of command where instructions from OpenAI, developers, and users have different authority levels, with some hard safety boundaries not overridable by users or developers. That is product design, safety design, and values design all at once. 

Again: not necessarily scandalous. Could be solely for structure. But, remember, structure shapes outputs. 

When your only interface is a glossy chat box, you do not see the hidden instructions, refusal policy, ranking behavior, retrieval choices, moderation layer, memory behavior, or product incentives. You see the answer. Maybe a typing animation. Maybe a sparkle icon, because apparently every serious software product now has to look a little bit like a toy.

Local Compute as a Lab Bench 

Local compute breaks that spell. Not completely; you still do not know the full training data, and you still inherit the biases and blind spots of the model. "Open weights" is not the same thing as full open source. The Open Source Initiative's Open Source AI Definition makes that distinction clearly: open source AI requires more than public weights. It also depends on the ability to use, study, modify, and share the system, along with sufficient data information, code, and parameters to inspect and modify it. 

But local models give you something hosted interfaces usually do not: a lab bench. You can inspect the prompt. You can see what changes when guardrails are absent, thin, strict, or custom. You can add your own. You can compare models. You can fine-tune. You can run private documents without shipping them to someone else's server. You can observe failure modes at the level where they happen. That matters more than people think. 

The Goal Is a Baseline, Not a Replacement 

The goal is not to replace every cloud model. Use cloud models. Use the best model for the job. If you need frontier reasoning, tool use, multimodal performance, or production reliability, the cloud will often win. 

The goal is to keep a local baseline. A local baseline is the epistemic equivalent of owning a multimeter. You may not use it every day, but once you have one, you stop believing every blinking LED is telling the truth by default.

Three Advantages of Local Models 

Local models give you three things. 

Inspection 

You see the model name, quantization, context window, sampler settings, system prompt, and prompt template. You learn that "the AI said" and "you're absolutely right" are not meaningful sentences. Which model? Which weights? Which prompt? Which temperature? Which context? Which retrieval layer? Which tool calls? Which hidden instructions? 

Friction 

Local models are slightly annoying. That is a feature. You have to choose the model. You have to wait for downloads. You have to notice VRAM. You have to think about context. You have to decide whether to run LM Studio, llama.cpp, vLLM, Transformers, ExLlamaV3, or some cursed weekend stack held together by CUDA, hope, and one GitHub issue from 2022. 

Tools like llama.cpp, ExLlamaV3, and vLLM have made local inference much easier, but they still expose enough of the machinery to educate you. That friction slows consumption. A glossy hosted chatbot wants to disappear into the background. Local compute keeps saying: no, this is machinery. Good.

Intuition 

You can read a thousand warnings about hallucination. It is different to watch a model invent a citation, defend it, apologize, invent a second one, and then summarize the fake paper with admirable confidence. 

You can read about sycophancy. It is different to watch a model slowly mirror your framing until your bad idea comes back to you wearing a lab coat. 

You can read about prompt injection. It is different to paste hostile text into context and watch the model treat it like higher authority. 

You can read about alignment. It is different to compare base, instruct, RLHF'd, distilled, and fine-tuned variants until "AI personality" collapses into training choices. 

That boredom is the antibody. At first, the model feels uncanny. Then it feels powerful. Then it feels broken. Then it feels useful. Eventually, it becomes what it actually is: a slab of matrices embedded in a stack of human choices. Once you get there, eloquence stops impressing you by default. 

That is the win. 

The Mental Health Angle 

This is also why the mental health angle needs to be discussed carefully, not theatrically. "AI psychosis" is a popular phrase, but it is too sloppy. It is not a formal diagnosis, and causality is not settled. 

UCSF psychiatrists describe "AI-associated psychosis" as cases where delusional beliefs emerge alongside often intense chatbot use, while explicitly noting the "chicken and egg" problem: chatbot use may be a symptom, a trigger, an amplifier, or some combination depending on the person and context. 

That uncertainty does not make the risk fake. It makes sloppy certainty dangerous. 

An April 2026 preprint on conversation history and delusional beliefs found that accumulated context can act like a stress test: some models resisted delusional framing, while others validated or elaborated it as the dialogue progressed. 

The important lesson is not "chatbots cause psychosis." The lesson is scarier and more useful: extended dialogue can create feedback loops, and different models handle those loops very differently. That is exactly the kind of thing you understand faster after running models yourself. 

You begin to see how a system can be useful without being trustworthy. How it can be supportive without being safe. How it can sound wise while merely continuing the frame you gave it. How "personalization" can become dependency if no one is careful. How a model trained to be helpful can become a mirror that does not know when to stop reflecting.

The Real Case for Buying a GPU 

This is the real case for buying a GPU. Not AGI. Not status. Not because the cloud is evil. 

Because cognitive self-defense now requires mechanical sympathy. You should know what these systems are good at. You should know where they fail. You should know how much of "the answer" comes from the model, the prompt, the policy, the retrieval system, the UI, and your own framing. 

So run the models. Break them. Stress-test refusal boundaries. Compare them. Fine-tune one badly. Make one summarize your own notes. Make one argue both sides of a position you care about. Make one hallucinate in a domain where you know the truth. Make one write something beautiful and wrong. 

Then repeat until the glamour wears off. 

A Microscope, Not a Firewall 

A GPU is not a firewall for your beliefs. 

A GPU is a microscope. It lets you see the machinery close enough that you stop confusing fluency with intelligence, confidence with truth, and convenience with alignment.

Conclusion 

AGI may be near. It may be far. It may be a category error. 

Influence machines are already here. Own the hardware if you can. Rent it if you cannot. Share it if that is what is available. Keep local copies of useful weights. Learn the failure modes. Use the cloud, but do not let the cloud be your only teacher. 

Cognitive security is becoming table stakes for living in a world where some of the most persuasive voices you encounter are not human, do not have stable beliefs, and are not necessarily optimized for your agency. 

So yes. This is still why I keep saying it: Buy a GPU.

P.S. 

Why run on your own hardware when cheap APIs exist? Because you cannot trust any infra that you do not fully control. 

Cheap APIs are not the (entire) problem. They are kinda a miracle actually. I use them daily. The problem is stopping there. 

When you send your thoughts through someone else's endpoint, you are renting a black box on terms you did not write, running on hardware you cannot inspect, shaped by policies that change without notice, and logged in ways you will never see. The price is low. The cost is opacity. 

You do not know what quantization they used. You do not know what system prompt they prepended. You do not know if your conversation is training data next quarter, or if a compliance review will flag a thread you thought was private. You do not know if the model was swapped last night for a cheaper variant with a different personality, or if the refusal boundaries were tightened because of a headline. You only know the output stopped feeling right, and you have no way to verify why. 

This is not paranoia. This is infrastructure. Infrastructure you do not control will not optimize for your understanding. It optimizes for cost, scale, liability, and engagement. Those are fine goals for a business. They are terrible goals for your cognitive development.

The "cheap API" argument also misunderstands what the GPU is for. It is not just about having a local copy of a model. It is about having a laboratory. You need a place where you can change one variable - temperature, context window, system prompt, fine-tuning data - and watch what happens. APIs abstract all of that away. They give you outputs. They do not give you mechanism. And mechanism is what turns a user into an operator. 

There is a deeper layer too. When everything you know about these systems comes from polished endpoints, your intuition forms around interfaces, not behavior. You learn what the product wants you to see. You do not learn where the model is brittle, where the policy overreaches, where the context window decays, or where the weights have memorized something poisonous. You learn to trust fluency because you have no tool to interrogate it. 

Buy a GPU, or rent the server, or borrow the machine. Run the weights locally. Break things on purpose. Build a small, dumb app that no one will use. Fine-tune a model on your own writing until it sounds like a parody of you. Watch a 7B model hallucinate confidently next to a 70B model that refuses correctly. See the difference between context and knowledge. Feel the shape of a system prompt you never wrote. 

Then go back to the APIs. They are still cheap. They are still convenient. But now you will know what you are buying, what you are not, and what you are giving away. 

Until next time.

Ahmad M. Osman is an AI researcher and systems engineer specializing in infrastructure and hardware. He's building toward a frontier, infra-first AI lab in the West. Ahmad is also a GPU moderator and open-source AI advocate on r/LocalLLaMA, one of the largest communities for running AI models locally. X | LinkedIn

_{Guest contributor: Scott is a UBI advocate, founder of the Income To Support All Foundation, and advisor to organizations advancing economic security and policy innovation.}

There's a new paper making the rounds called "The AI Layoff Trap", by Brett Hemenway Falk and Gerry Tsoukalas, and it arrives with a headline that's catnip for anyone looking to wave off basic income. Among the policies that can't fix the problem of AI-driven layoffs, they list universal basic income. Right there in the abstract, sitting next to capital income taxes and upskilling and worker equity. Only one tool makes the cut: a Pigouvian tax on automation.

I want to take this paper seriously, because the core idea is genuinely good. And then I want to show you exactly where it goes wrong about UBI, because it's the kind of error that's easy to miss. It's simply a flawed assumption.

The Good Part

Here's the automation trap the authors describe, and it's a real one.

When a company replaces workers with AI, it pockets the full savings. But those laid-off workers were also customers. Their vanished paychecks mean vanished spending, and that lost spending doesn't only hit the company that did the firing. It hits everyone selling anything. The catch is that each firm eats only a small slice of the demand it destroys. The rest lands on its competitors.

So every firm faces the same math: automate, capture all the savings, and shove most of the pain onto rivals. Everybody reasons this way at once. Everybody automates past the point that's good even for the owners. This is the classic tragedy of the commons problem. Everybody eventually ends up worse off. And it gets worse the more competitive the market is, and worse the better the AI gets. "Better" AI doesn't save you. It just speeds up the race toward the cliff.

I think it’s useful to explain all of that. It puts some math under something a lot of us have been saying in plainer words for years: an economy that automates away its own customers is sawing off the branch it's sitting on. Credit where it's due.

The Flaw That’s Baked In

Now watch what happens to UBI.

In their model, a basic income is a single thing: a constant. They call it A, for "autonomous demand." Everyone gets the same check whether they're working or laid off, so it adds a flat amount of spending and then drops out of the equation that decides whether a firm automates. Their conclusion follows immediately. A flat number that doesn't change the marginal cost of firing one more person can't change the decision to fire one more person.

But look at what just happened. They defined UBI as a thing that can't affect behavior, and then discovered that it doesn't affect behavior. The conclusion was embedded inside the assumption. To their credit, the authors say as much in a quiet caveat that the result "should not be read as a verdict on all UBI designs." That caveat deserved to be the headline. It wasn't.

Their own model hands me my rebuttal. Buried in the math is a dial they call η — the share of a displaced worker's lost income that comes back through "reemployment, transfers, or other sources." Turn that dial up and the trap shrinks. Turn it up far enough and the whole thing flips into under-automation. The authors let wage insurance and severance touch that dial. They just don't let UBI touch it.

Why not? Because they modeled UBI as a check that changes nothing about what a laid-off person does next. But that's not what a basic income does. A floor under everyone changes who can afford to retrain, who can afford to hold out for a good job instead of grabbing the first bad one, who can afford to start new businesses, who has the power to say no to low wages and insist on better pay for jobs that can’t be automated yet. Every one of those is η. UBI doesn't just raise A. It raises η. And the paper's own framework says raising η is exactly what closes the trap.

What the Model Can’t See

There's a second thing the model can't see, and it's the one I care about most.

In their world, a human-made thing and an AI-made thing are the same thing. So income only ever shows up as how much people spend. Never what they choose to buy. Money is money.

That's not how consumers work. Give someone a stable floor and they don't just spend — they spend differently. They pay for the live band instead of just the Spotify subscription. They pay extra for the handmade thing, the local thing, the human experience. Human labor becomes a premium — the new "Made in the USA,” but instead “Made by Humans”. That's a market signal for human labor even when it costs more, and spending power is what creates it. The model can't represent any of it, because its one lonely demand term can't bend in that direction. A real basic income doesn't just adjust the volume knob. It changes the song.

And we're not guessing about whether basic income ripples through the wider economy. Alaska has paid every resident a universal dividend since 1982, and when economists Damon Jones and Ioana Marinescu studied it, they found it had no effect on overall employment — and actually nudged part-time work up, consistent with the cash stimulating the local economy. A general-equilibrium effect. Which is precisely the dynamic feedback the model assumes out of existence the moment it freezes UBI into a constant.

The Harm Isn’t the Automation

Here's my deeper problem with the paper, and it's the one that matters most.

The authors call this a negative externality and reach for the textbook fix: a Pigouvian tax, the kind you'd slap on pollution — tax the harmful thing. But automation isn't pollution. Automating human labor is usually a good thing. It's how we get more for less. It's how a crew of twenty becomes a crew of five — and, in a sane system, how all of them get some of their lives back. Depending on the work, automation runs from neutral to genuinely wonderful. Almost none of it is harmful in itself.

So why does the model see harm everywhere a job disappears? Because of one assumption it quietly shares with our entire economy: that a person's income is coupled to their job. Cut someone loose from their paycheck and yes, their spending collapses, and yes, that ripples out onto everyone. But that chain reaction isn't a property of the robot. It's a property of the rule — our rule, the one we wrote ourselves — that says you only get to eat if you have a job, and you only get money if someone pays you to work.

That's the externality. Not the automation. The income-from-labor link. We built a system where one person's lost wage is the next person's lost customer, and then we act surprised when the system starts eating itself.

Automation can be a problem. I won't pretend otherwise. But it doesn't have to be. It only is so long as things stay exactly as they are — where people need jobs to live, and jobs need consumers who can spend. Break that link, even partway, and the trap loosens. Give people a floor that doesn't vanish the moment their job does, and a laid-off worker is still a customer, still spending, still part of the economy. A basic income is how you keep at least some of the wage without requiring the work. That non-zero floor will then enable more choices and also more income.

So Tax It — but Not as a Sin

Notice what the authors want their tax to do: slow the robots down, pull automation back to the level that's collectively "optimal." I don't want that. I want the robots to go as fast as they safely can. What I want to change isn't the speed of automation — it's who it's for.

So tax it, sure. Just not as a penalty for the crime of automating. Tax it the way you'd tax any rich, jointly-created stream of value: to fund the dividend and spread the gains. And here's the contest the paper sets up that was never a contest — UBI versus the tax. UBI has always needed funding, and the funding is the tax. One taxes and one distributes. They aren't opponents. They're two sides of the same coin. The paper even admits it, calling UBI "a complement to the automation tax, not a substitute" — a strange thing to bury after stamping "neither can universal basic income" across the abstract.

And I'd go further than one tax, because no single tax should have to carry an entire economy. Tax land value — the value the community creates, not the building on top of it, what Milton Friedman called the "least bad tax". Put a tiny tax on every financial transaction. And for the AI age specifically, I'd add a stock-dilution tax: require public companies to issue something like 1.5% of new shares each year into a national wealth fund whose dividends flow to all of us. If capital is going to eat labor, then let us own the capital, together. Fund the dividend out of the very automation that threatens the paychecks, and watch the incentives flip — because the more we automate, the more everyone gains.

What the Paper Actually Proved

Stated honestly, the finding is narrow and fine: in a stripped-down model where AI eats consumption and UBI is defined as a number that can't change anyone's behavior, UBI doesn't change anyone's behavior. Coherent, and almost entirely beside the point.

Because the real question was never whether flat cash, all by itself, changes a firm's automation math. The real question is what kind of world we build on the far side of all this automation. The trap the authors describe is real. The way out isn't to pick the tax over the dividend. It's to tax automation and hand the proceeds back to the people as a dividend that rises as the robots do.

UBI isn't the policy that fails to stop the trap. UBI is how we make sure that when the machines do the work, the people still get to live, and thrive.

And if you want to do more than nod along, this is exactly the moment I built the AI Pledge for Humanity for. It's a public stand for the simplest version of the idea — that the gains from AI belong to all of us, as a rising basic income floor framed as an AI dividend — and a way to hold the AI leaders who keep saying UBI is inevitable to actually helping make it real. Sign it. Share it. The people building the machines keep telling us this is coming. Let's make sure they help build the floor that catches us and uplifts us when it does.

Remember: jobs are for machines; life is for people.

Scott Santens is a writer and advocate for Universal Basic Income (UBI). He is the founder and CEO of the Income To Support All (ITSA) Foundation and the creator of the AI Pledge for Humanity, which calls on AI leaders to back their words about UBI with action.

_{Guest contributor: Gopi Kallayil is Chief Business Strategist for AI at Google, board member and advisor to CEOs, TEDx speaker, and former McKinsey consultant.}

The answers were surprising. First, it determined that guests cared more about breakfast than fine dining experiences. They’d been investing heavily in prestigious dinner restaurants with celebrity chefs, but guests really wanted an excellent breakfast. Second, 90% of breakfast orders were modified. 

So they made a bold decision: they removed the breakfast menu entirely. Through my work at Google and the years I’ve spent in Silicon Valley, I’ve witnessed multiple technological breakthroughs—from the internet to mobile phones to smartphones. And I’ve observed one consistent pattern that AI is now confirming: travel and hospitality are always among the first industries impacted by new technology. 

Why? Because while the “product” of travel is physical and experiential, everything leading up to it is purely informational. You can’t walk into a store and try on a vacation. The entire experience is built on research, communication, and planning, which is exactly the kind of information-dense processes that technology transforms. 

Put simply, if you want to know how a new technology will affect your industry, look at what’s happening in travel and hospitality. That’s where you’re likely headed. 

I’ve identified four specific dimensions where AI is currently transforming the hospitality and travel industries. Understanding these patterns will help you recognize similar opportunities in your own industry. The real prize will go to those who can identify new opportunities that hit on all four dimensions simultaneously. 

Dimension 1: The Customer Journey

The traditional vacation planning process involves days or weeks of research—scrolling through articles, watching videos, browsing Instagram, and reading reviews. The exploration phase alone can consume hours, and it’s a significant enough barrier that it prevents some trips from ever coming to fruition. 

AI is collapsing this entire process from hours or days into minutes. 

I recently demonstrated an AI assistant to a room of hospitality executives. I held up my phone and said, “I’m planning a vacation to Marbella, Spain. Recommendations for luxury resorts?” The AI responded conversationally, listing the Marbella Club Hotel, Puente Romano Beach Resort, and Nobu Hotel Marbella—immediately providing context about each property. 

Then I asked, “Does Puente Romano have yoga classes? What about a spa?” The AI provided detailed information instantly. This research used to require visiting multiple websites, reading dozens of reviews, and possibly calling properties directly. 

Imagine a world where you have an AI agent that knows all of your preferences, travel history, schedule, and goals. Planning an entire vacation could be as simple as speaking a few sentences—from finding the cheapest flight that maximizes your reward points to developing daily itineraries with bucket list items. 

AI is already removing friction from travel planning, and we’re going to see similar trends across all industries. 

Dimension 2: AI-Powered Marketing 

Marketing in hospitality has traditionally focused on maximizing immediate bookings—getting people to book right now. But AI now enables many different approaches by synthesizing vast amounts of data and generating insights that would take humans thousands of hours. 

Hilton Hotels provides a perfect case study. Instead of treating all customers the same, they asked: What if we could identify exactly what each type of guest actually values? They analyzed millions of Hilton Honors loyalty program profiles and booking behaviors, enabling far more granular segmentation than ever before. 

Their AI models could identify patterns like which guests value breakfast inclusion versus lowest price, or which corporate accounts show potential for weekend travel. They used these insights to deliver personalized pricing and targeted promotions to their customers—in other words, they could reliably send the right offer to the right guest at the right time.

The result was a 5-8% increase in revenue, alongside higher guest satisfaction because customers received offers that actually matched their preferences.¹ The AI helped them spend their marketing budget more wisely by understanding what different guests truly wanted and tailoring their approach accordingly. 

Dimension 3: Service Delivery and Guest Experience 

At this point in my life, there’s no hotel chain I haven’t stayed at. Given the amount of data these companies have, they should know quite a bit about me. 

Yet when I check into a typical hotel chain, the front desk clerk often treats me like a complete stranger. They don’t know how to pronounce my name. They spend three minutes explaining the same checkout procedure I’ve heard hundreds of times. They don’t know that I prefer a high floor and frequently request a late checkout. 

The data is absolutely there. They’re just not connecting the dots. 

Now, some luxury hotels already do this manually. But the reality is that AI will bring this level of personalized service to every hotel chain. 

Imagine a hotel where the front desk automatically sees an AI-generated summary as you check in: “Based on past stays, this guest is interested in local yoga studios, prefers high floors, usually requests late checkout, and appreciates vegetarian restaurant recommendations. They stayed at our London property last week, so skip the checkout policy.” 

That simple piece of AI-generated intelligence transforms the entire interaction. The data and the AI systems we have today are already capable of doing this. And there are even more opportunities for similar transformations that we simply can’t predict. 

For example, the Beverly Hills Hotel in Los Angeles recently made a major change based on AI insights. They built a tool called Metis to read thousands of reviews across platforms and identify patterns. They asked it one simple question: “What do our guests care about most?”. Now, when you sit down for breakfast at The Beverly Hills Hotel, the server simply asks what you’d like to eat. You can ask for anything, and they’ll make it. How’s that for luxury?

Dimension 4: Operational Excellence 

Behind the scenes, AI is transforming hotel operations in ways guests may never see directly but experience through better service, lower prices, and improved sustainability. 

I was talking recently with the operations manager of a resort who described one of the challenges that keeps him up at night. “One week, we’ll have the entire property booked with families on vacation. The next week, a company will book the whole hotel for a corporate offsite, and the operational dynamics are completely different.” 

When you have leisure guests, the pool is packed—you need lots of pool attendants and towels. Families are everywhere, kids are running around, and the casual restaurant gets slammed at lunch. The bar is dead at night. 

When you have a corporate group doing team-building and strategy sessions, it’s almost the exact opposite. The pool stays quiet, the bar is busy, and coffee service needs to run continuously during the day for meeting breaks. Suddenly, you need eight bartenders instead of three and one pool attendant instead of four. 

Right now, hotels handle this through manual planning and educated guesswork. Yet AI can predict with remarkable accuracy exactly what staffing and resources will be needed based on guest profiles, historical patterns, booking data, and external factors. This means better service for guests, lower costs for hotels, and less stressful work for operations teams. 

What This Means Beyond Hospitality 

Whether you’re in healthcare, financial services, manufacturing, retail, or professional services, you have customer journeys where AI can reduce friction, marketing opportunities where AI can identify high-value customers, service delivery touchpoints where personalization drives loyalty, and operational processes where AI can dramatically improve efficiency. 

The specific applications differ, but the transformation pattern remains identical. 

AI will disrupt and transform nearly every industry. Travel and hospitality are simply where we’re seeing it first and most clearly, just as we have with every other technological breakthrough. By understanding what’s happening in travel right now, you can anticipate and prepare for similar transformations in your own sector.

The true winners will be the non-linear thinkers who can identify new products, services—even entirely new industries—that capitalize on all four dimensions simultaneously. 

Which of these four dimensions represents the biggest opportunity for your organization?

Gopi Kallayil is Chief Business Strategist for AI at Google, advising global organizations on AI, digital transformation, and business growth. A board member, CEO advisor, TEDx speaker, author, and former McKinsey consultant, he is recognized for helping leaders leverage technology to drive innovation and strategic impact.

_{Guest contributor: Ethan Wang is founding member of Google DeepMind Spark agent and founding member of Google DeepMind Mariner Agent.}

Most agent projects that miss the quality bar actually do not miss because the model is too weak. They miss it because the tools are too sophisticated, the system instructions are too crowded, or the team tries to evaluate quality before the plumbing actually works. This note distills the principles and the sequence — These insights come from developing several state-of-the-art agents. One notable project involved an autonomous music-video director created in just one month through approximately eighty manual iterations.

1. The Mental Model

A capable agent is one that can solve problems we did not script. That power does not come from a long instruction list; it comes from the agent's freedom to call the tools we give it, in whatever order it decides, as many times as it needs. The clearest mental model is linguistic:

Tools are words. The agent writes the sentence. Capability grows by adding more words — never by scripting more sentences.

Figure 1 — Tools are the agent’s vocabulary; the workflow is a sentence the agent composes at runtime.

Once this frame clicks, almost every design decision gets easier. When you find yourself reaching for a switch-statement inside a tool, or a conditional branch inside the system prompt, you are scripting a sentence. Stop, and add a word instead.

2. Two Pillars of Tool Design

If tools are words, then the three properties that make a language usable also describe what makes an agent's toolset usable: each word means one thing, each word is defined precisely, and the surrounding grammar (the system instructions) stays out of the way.

Pillar 1 — Single Responsibility

Every tool should be one verb. analyze_song. plan_story. generate_shot. critique_shot. cut_jump. assemble_section. The moment a tool sprouts a mode parameter, you have stapled several tools together and now the agent has to guess which mode is valid with which options. That guessing is where bad runs come from.

Figure 2 — A mega-tool with modes forces the agent to guess. A row of small, single-purpose tools lets it choose.

An agent reads tool descriptions the way a careful translator reads a dictionary. Each tool needs a one-line summary of what it does, an explicit statement of when to use it (and when not to), the exact input and output shape, and the failure modes it can return. Two tools that sound similar will get used interchangeably; if you cannot describe each in one sentence that distinguishes it from its neighbours, the design is not done.

Pillar 2 — Simple, Stable System Instructions

The system prompt should hold only what is true on every single turn: the agent's role, the path it writes outputs to, hard ground rules. Doctrine that is conditional ("when the song intensifies, shorten the shots") belongs in the tool that owns that decision, not in the global prompt — once it lives at the top, it pollutes every unrelated decision the agent makes. A short, clean prompt plus a rich toolset beats a long prompt with a thin toolset, every time.

Figure 3 — Where the rules live. Keep each layer doing only its job.

3. The Build Sequence: Infrastructure First, Then Hill-Climb

The single most common reason eval programs fail is that they start too early. If a tool sometimes silently returns the wrong field, or two tools collide on the same scratch path, no amount of clever scoring will tell you anything useful — you'll just measure your bugs.

Figure 4 — Two phases, in this order. You cannot hill-climb on a broken foundation.

Phase 1 — Get the Infrastructure Right

In this phase, the bar is correctness, not quality. Before you measure anything, confirm that:

• Every tool does exactly what its doc says, with the input and output shapes documented.

• Errors are structured and informative — {error, hint} rather than a stack trace — so the agent can recover.

• Side-effects are explicit (the tool that says it writes a file is the only tool that writes a file).

• Outputs are isolated per run — no two runs can ever overwrite each other.

• There are unit tests at the tool boundary; if you cannot test a tool in isolation, it is doing too many things.

This phase is unglamorous and easy to skip. Skipping it produces evals you cannot trust and a hill-climb that wastes weeks.

Phase 2 — Eval and Hill-Climb

Only now does it pay to turn quality into a number. Pick a target the agent should match — a reference output, a rubric, a human score — and have a critic produce a single graded comparison per run. The number doesn't have to be perfect; it has to be consistent enough that you can tell whether a change made things better or worse.

4. Hill-Climbing in Practice

Figure 5 — The hill-climbing loop. Run it manually first; once it works, automate it.

Each turn of this loop has only one job: turn one specific observed defect into one specific addition to the agent. The addition takes one of three forms:

• A new/better tool — when the agent is missing a word it needs. ("It cannot vary the cut rate, so it doesn't." Give it cut_jump, cut_match, assemble_section.)

• A new critic or soft gate — when a rule must always hold. The critic refuses or rewrites with a structured hint the agent can act on.

• A doctrine line — added to the specific tool's documentation where it applies, not bolted onto the global prompt.

Done patiently, the curve looks like Figure 6. Each labelled step is a real lesson encoded back into the agent: character identity anchored by spec; hard cuts only; the song analysis made the mandatory first step; the planning phase grown to ~70% of the run; and finally, the AI-feel score loop closing the gap unattended.

Figure 6 — Quality vs. iterations on the music-video director. Each annotation is one observed defect, encoded once.

Two notes on this curve. First, the early gains are large and the late gains are small — that's expected; you are running out of obvious defects. Second, the steepest drops come from infrastructure-class fixes ("ground-truth the song first", "storyboard-first"), not micro-tweaks. When a graph plateaus, the next jump usually requires re-thinking which words the agent has, not nagging it harder in the prompt.

5. Distilling New Tools From Real-World Runs

The hill-climbing loop in §4 is human-driven: a person watches a run, names the defect, encodes a lesson. The next step — and the one that compounds — is letting the agent's own runs surface the next words it needs. The principle is simple, and it falls straight out of the linguistic frame:

When the agent keeps composing the same sub-sentence — that is the missing word.

Figure 7 — Recurring tool-call sub-sequences are evidence of a missing primitive. Distill them into new vocabulary.

How It Works

Log every run's full trajectory — the tool calls the agent made, in order, with arguments and reasoning. Across many real runs you start to see two signals:

• Repeated sub-sequences. The same three or four tool calls in the same order, on different inputs. That sequence is the agent inventing a primitive that should have existed.

• Workarounds and shims. The agent is gluing existing tools together with zero-effect parameters (cross_fade(0ms), assemble on a single shot, retry-with-tweaked-prompt). It is faking the verb it wishes you had given it.

Either signal is enough to propose a new tool. The agent itself can do the proposing: feed it its own trajectory log and ask it to name the recurring pattern, write a one-line description, sketch the signature, and list the failure modes. A human (or a second agent) accepts or rejects; accepted tools get added to the vocabulary, and future runs use them directly.

Concrete Examples From the Music-Video Director

Two of the most useful pieces of the music-video agent emerged exactly this way, by watching what the agent kept trying to do with the tools it already had:

• Scene-cutting primitives. Early on the agent had only generate_shot and assemble. To make a hard cut, it would generate two shots, splice them with a zero-length cross-fade, and hope. The same pattern showed up in run after run. The lesson was not "prompt it harder to use better cuts" — it was that the agent had no word for a cut. Distilling those repeated sub-sequences produced the seven cut primitives: cut_standard, cut_jump, cut_on_action, cut_cross, cut_montage, cut_match, assemble_section. Each one is a single verb the agent now reaches for directly.

• Camera-movement taxonomy. The agent kept writing long natural-language motion clauses inside its shot prompts — "slow push-in while panning left, then settle." These free-form clauses were inconsistent and hard to critique. The repeated improvisation revealed a missing vocabulary: a named set of camera moves (push-in, dolly, whip-pan, crash-zoom, …) exposed as a tool with advisory hints. Once that vocabulary existed, both planning and critique sharpened.

The Self-Recursive Loop

Notice what has happened: the agent's runs become training data for the next version of the agent's toolset. Better tools produce different runs, which surface different missing words, which become the next tools. The loop runs on itself.

Two things keep this loop healthy. First, treat vocabulary growth as costly — every new tool the agent has to consider is a small tax on every future decision, so the bar to admit one should be "this sub-sentence shows up across many runs, on different inputs, and the distilled version genuinely simplifies them." Second, when a distilled tool ships, retire the workaround patterns that motivated it — leave them in the prompt and the agent will keep falling back to them. The vocabulary should grow, but it should also stay clean.

6. Hard-Won Lessons

Make Changes Surgically, and Protect a Known-Good Baseline

The most painful failure mode is the well-intentioned global edit. You add one new feature — say, an image-anchoring step — and quality on story, cuts, and pacing all silently regress, because that change touched the part of the prompt every other decision flows through. The rule that emerges: when a change degrades existing behavior, revert to the last known-good trunk and redo it surgically. Quality is a thing you protect, not just a thing you add to.

Critics Encode Doctrine. Tools Encode Choices

Anything that must always be true belongs in a critic or a soft gate — a check that refuses or rewrites with a structured hint. Anything the agent could reasonably decide either way belongs in a tool. This split keeps the agent free to be creative inside the boundary, while the boundary itself is enforced mechanically.

Preserve the Agent’s Freedom

When a proposal would replace a decision with a lookup table, refuse it. Determinism is good for safety and bad for creativity. Give the agent a tool plus a strong recommendation; let it call the tool — or not — based on the situation it actually sees.

Debug by Reasoning Before Debugging by Coding

When the agent does something wrong, the most productive first move is not to patch the prompt. It is to ask: why did this happen? And — equally important — why did this never happen before? Tracing a regression to its root cause almost always reveals a missing word in the vocabulary, or a recently-added word that confuses two existing ones. Either way, a code fix follows from understanding, not the other way around.

7. A Short Checklist

Before you ship a new agent — or before you decide an existing one is stuck — walk through this list.

• Can every tool be described in one sentence that distinguishes it from its neighbours?

• Does any tool have a mode parameter? If yes, split it.

• Are tool errors structured ({error, hint}) so the agent can recover without human help?

• Is the system prompt short — only role, paths, and rules true on every turn?

• Is there one number that grades the agent's output, computed by a critic and not by hand?

• Is there a known-good baseline you can revert to in one command?

• After each loss in quality, can you point at exactly which change caused it?

Appendix — How Quality Climbed on the Music-Video Director

The eras the project moved through, with the lesson encoded at each step. Every row started life as a watched video and a complaint that named the defect.

Ethan Wang is a member of Google DeepMind, focused on building general-purpose agents on the path to AGI. He is a founding member of two of the org's flagship agent projects: Gemini Spark, the recently released general agent; and Mariner, company's first computer use agent.

_{Guest contributor: Janakiram MSV is principal analyst at Janakiram & Associates, an independent analyst and advisory firm focused on cloud-native infrastructure, platform engineering, and agentic AI. He writes for Forbes, The New Stack, and Forward Future.}

Every serious AI agent platform in 2026 is running the same handful of frontier models from Anthropic, OpenAI, and Google. Same APIs, same context windows, same benchmarks. And yet some of these platforms ship reliable production agents in weeks while others spend nine months in prototype hell. The model has stopped being what separates them.

What separates them now is the operating system wrapped around the model, a layer the industry has started calling the agent harness, and it has quietly become the most consequential part of the AI stack.

The companies winning in production AI right now, Anthropic, OpenAI, Amazon, and a noisy open-source community, have shifted their gravity accordingly. They have stopped competing on raw model access and started competing on the thing that wraps the model. The scaffolding that turns a stateless text generator into something that can read files, run shell commands, browse the web, persist memory across sessions, and recover when a tool call fails halfway through. Get the harness decision wrong, and you will spend a year rewriting orchestration code while your competitors ship.

What a Harness Actually Is

An agent harness is the runtime infrastructure surrounding a language model that handles everything the model cannot do on its own. The model can reason about a task, but it needs the harness to actually carry one out. Anthropic's engineering team puts it plainly. The Claude Agent SDK, they say, is "a powerful, general-purpose agent harness adept at coding, as well as other tasks that require the model to use tools to gather context, plan, and execute". A LangChain engineer coined a cleaner formulation that has caught on. "If you're not the model, you're the harness."

The mental model is straightforward. The language model is the CPU, and the harness is everything else, the file system, the network stack, the shell, the scheduler. In practice, a harness manages the agent loop, orchestrates tools, decides what context to keep and what to compact, persists state across sessions, enforces guardrails like timeouts and step limits, recovers from failed tool calls, and logs everything for debugging and evaluation.

LangChain demonstrated this dependency in a way that should have ended the "model is the product" conversation for good. Same model, same weights, different harness. Their deepagents-cli coding agent jumped from 52.8 percent to 66.5 percent on Terminal-Bench 2.0, which the team described as moving from outside the Top 30 into the Top 5. The intelligence stayed exactly where it was. All of that gain came from better scaffolding.

Four Harnesses, Four Philosophies

The interesting part is not that harnesses exist. The interesting part is that the major AI providers have each made very different bets about what a harness should be. The four examples below sit at different maturity levels, from generally available SDK to limited preview to community project, but together they map the design space the industry is converging on.

Claude Managed Agents: The Model Lab As the Harness Vendor

Anthropic released Claude Managed Agents in public beta on 8 April 2026. You define the model, the system prompt, the tools, the MCP servers, and the skills. Anthropic runs the agent loop in its own managed environment, complete with prompt caching, context compaction, and a secure execution sandbox.

What is striking about this product is who is selling it. The model lab itself is now in the harness business. Anthropic's own engineering writing shows that Claude's agentic performance depends heavily on harness assumptions, and that those assumptions can become stale as models improve. By offering the harness as a managed product, Anthropic is selling the full performance envelope of its model, not just the API. The Claude Agent SDK is the open-source companion, exposing the same harness that powers Claude Code in Python and TypeScript libraries for teams that want to run it in their own infrastructure. Both products carry the same message. Anthropic now treats the harness as part of the model's value, and it intends to own that layer rather than leave it to someone else. 

Bedrock AgentCore: The Hyperscaler As the Harness Vendor

Amazon took a different route. Amazon Bedrock AgentCore launched its Managed Harness in preview on 22 April 2026. AWS describes the architecture cleanly. "Every agent has an orchestration layer which contains the loop that calls the model, decides which tool to invoke, passes results back, manages context windows, and handles failures. Running that loop requires infrastructure underneath it ... This infrastructure forms the agent harness."

AgentCore Managed Harness lets a developer define an agent in three API calls. Pick a model, write a system prompt, list the tools. AWS handles compute, microVM sandboxing per session, identity, VPC networking, memory, and observability. What AWS does differently is multi-model from day one. The harness supports Bedrock, OpenAI, and Google Gemini, and can switch providers mid-session without losing context. Rather than bet on a single model winning, AWS is betting that the harness is where lock-in happens, and that owning the harness gives them durable customer ownership regardless of which model wins.

AWS then went a step further. On 28 April 2026, AWS and OpenAI announced Bedrock Managed Agents powered by OpenAI, a separate limited-preview product built around what AWS calls the OpenAI agent harness, packaged with AWS security, identity, and data residency. That phrasing is worth reading twice. Amazon is now reselling OpenAI's harness, with the two companies announcing it jointly. The harness has become a tradable asset.

OpenAI’s Agents SDK and AgentKit: The Harness as a Developer Journey

OpenAI's harness story changed materially on 15 April 2026 with the next evolution of the Agents SDK. What used to be a relatively thin orchestration library is now a model-native harness with native sandbox execution, configurable memory, Codex-like filesystem tools, support for MCP and AGENTS.md, and a Manifest abstraction for describing the agent's workspace. Developers can plug in sandboxes from Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, or Vercel, or bring their own.

OpenAI's own framing of the update is revealing. They name three existing trade-offs explicitly. "Model-agnostic frameworks are flexible but do not fully utilize frontier models capabilities; model-provider SDKs can be closer to the model but often lack enough visibility into the harness; and managed agent APIs can simplify deployment but constrain where agents run and how they access sensitive data." The new SDK closes all three gaps at once.

This sits underneath AgentKit, the broader developer suite OpenAI launched at DevDay 2025, which packages Agent Builder for visual workflows, ChatKit for embeddable UI, and Evals for tracing and quality. The combined story is now a developer journey, not a single runtime. Start in Agent Builder with drag-and-drop, ship a chat UI with ChatKit, drop down to the Agents SDK for code-level control, and ride the same harness all the way to production. The practitioner consequence is portability. With the April 2026 release, OpenAI has effectively answered Claude Agent SDK with a comparable model-native harness, while keeping the visual-builder and embeddable-UI layers as a parallel funnel. Once your workflow lives in Agent Builder, your UI lives in ChatKit, and your runtime lives in the Agents SDK sandbox, leaving OpenAI stops being a simple model swap and becomes a full re-platforming exercise. OpenClaw: The Harness as a Community Artefact

OpenClaw is one of the more visible open-source harnesses operating outside the major labs. It runs autonomous agents on top of Claude, GPT, Gemini, or local models, and ships with messaging-channel integrations for Telegram, Discord, Slack, and WhatsApp. The community has built layers on top of it. AlphaClaw bundles a self-healing watchdog, Git-backed rollback, and a browser-based dashboard. The OpenClaw Harness repo adds a structured Sprint plan-build-review-iterate-ship pipeline, modelled on how human engineering teams actually work.

The wider open-source harness ecosystem is maturing fast around it. Hermes Agent, released by Nous Research in February 2026, has crossed 27,000 GitHub stars and now ships with an explicit OpenClaw migration command. That a community project considers cross-harness portability a first-class feature tells you the harness layer is now mature enough to have switching costs worth migrating away from.

OpenClaw matters for two reasons. Its design philosophy is community-driven rather than vendor-driven, and its growth has been visible enough that Anthropic adjusted its subscription policy in response. In April 2026, Anthropic restricted OpenClaw and other third-party agent harnesses from Claude subscriptions, citing capacity and caching inefficiencies. In May, Anthropic reversed the restriction and introduced a separate Agent SDK credit tier. Users got their access back. Anthropic got billing protection. The OpenClaw episode is a useful tell. The harness layer is now important enough that subscription economics have to be redesigned around it.

What This Means if You Are Building or Buying

Three things follow from this shift.

First, the harness is where your switching costs are going to live. Models are increasingly interchangeable for many enterprise tasks, but harnesses are not. If your agent's logic lives in an Agent Builder visual workflow, or in a Claude Managed Agent configuration, or in an AgentCore harness manifest, the portability question is no longer "which model" but "which platform". Pick deliberately.

Second, the choice between managed and open-source harness is not analogous to the managed-versus-self-hosted database call. A managed harness gets you to a working prototype in three API calls and an afternoon. An open-source harness gets you control over how the agent loop actually behaves, which matters when you are debugging why an agent burned through 400,000 tokens to write one PR.

Third, the model lab's harness will probably always perform best on its own model. Anthropic's own engineering writing emphasises that harness assumptions are tightly coupled to model behaviour, which is why third-party harnesses sometimes show regressions even when the model upgrade should help. If you are running Claude in production at scale, the Claude Agent SDK or Claude Managed Agents will likely outperform a generic open-source harness on the same task. The cost of that performance is platform commitment.

The Contrarian Read

The reason the harness story is bigger than it looks is that it inverts the assumed direction of AI value capture.

For the last three years, the working theory has been that the model labs sit at the top of the stack and capture most of the value, while infrastructure providers and application developers split the rest. That theory assumed the model was the scarce resource and everything else was a commodity.

In 2026, the labs are racing to ship harnesses, and the hyperscalers are racing to resell them, because everyone has realised the same thing. The harness is what turns a model into a product. The harness is where the orchestration code, the tool integrations, the memory schemas, and the operational know-how accumulate. Frontier model quality still matters, but for many production agent workloads, switching costs are moving upward from the model API into the harness.

If you are placing AI infrastructure bets in 2026, the question is no longer which model is best for your use case. It is whose harness you want to commit to for the next three years, because that decision will quietly outlast the next several model generations and shape everything you build on top of it.

David Shapiro Janakiram MSV is a principal analyst at Janakiram & Associates covering cloud-native infrastructure, platform engineering, and agentic AI. He writes at: thenewstack.io/author/janakiram/

Try Workbench free for 20 min/ day →

REAL OR AI

One of these was made by AI. Which one?

Stream for Free

Higgsfield is the world's first AI-powered streaming platform, dropping original series made entirely by artificial intelligence. No studios, no gatekeepers, no $200M budgets. Just stories that shouldn't exist yet, streaming right now for free.

Stream for Free.

Guest contributor: David Shapiro is an independent researcher and writer focused on post-labor economics and AI futures. We're glad to have his perspective in the mix. His views are his own and don't reflect Forward Future's editorial positions.

The easiest mistake to make about Anthropic is to treat it as “OpenAI, but with a conscience.”

That story is emotionally satisfying but overly simplistic. OpenAI was the first-mover, ostensibly motivated by “AGI for the benefit of all humanity” which, at the time of writing, is still in their charter. On the surface, this sounds very similar to Anthropic’s morality.

After all, Sam Altman is easy to read, what you see is what you get. He wants money, power, control, and the largest possible seat at the table. There is nothing particularly mysterious about that. Throw a dart blindfolded in the Bay Area and you’re bound to hit a founder with the same goals.

Anthropic is harder to read because it speaks in a different register. They talk about safety and alignment, but they go beyond the CBRN and cybersecurity risks that OpenAI focuses on. Anthropic adds in x-risk, and lately, geopolitical dominance as its top-of-mind concerns. They don’t just want to win the AI race on business terms, they believe they have a personal mission to save humanity. 

That is precisely why they deserve more scrutiny.

Anthropic publishes AI safety research, just like OpenAI. Likewise, Dario Amodei has spoken with the same moral seriousness and gravity as Sam Altman about risks to humanity. It was Sam, after all, who went before Congress to say “lights out for us” as the worst-case scenario. On paper, there’s not much difference between Sam and Dario.

So, why am I making the case that Anthropic deserves just as much scrutiny as OpenAI? What makes them stand out as “more dangerous”? 

The First Rule Is Simple: Follow the Money

Anthropic’s rise this year has been meteoric. The company reportedly crossed a $30 billion annualized revenue run rate by April, up from about $9 billion at the end of 2025. Meanwhile, OpenAI had reportedly topped $25 billion annualized revenue as of the end of February. While these numbers are not published by the SEC, the trend is undeniable. Anthropic is no longer the safety lab throwing stones at the establishment.

But who is Anthropic’s customer? OpenAI’s flex is that they serve 900 million humans around the globe. Sam Altman came up through Y Combinator, and at the time, they worshipped the Facebook model. Volume was everything. If you can capture most of the world’s internet users, revenue will come. Anthropic took the opposite approach. Taking a page out of Alex Hormozi’s book, Anthropic decided to “sell to the richest people you can.” In this case, that is Fortune 500 companies. 

To that end, Anthropic has surpassed OpenAI’s enterprise adoption, according to Ramp adoption data. Anthropic leads with 34.4% to OpenAI’s 32.3%, driven largely by Claude Code.

The takeaway here is simple. Anthropic serves the corporate establishment, first and foremost. 

That Brings Us to the Second Rule: Actions Speak Louder Than Words

Anthropic’s public image is presently shaped by the idea that it “stood up to the Pentagon.” But the more nuanced version is far less heroic. Dario was first in line to get in bed with the Pentagon. Amodei said Anthropic had “worked proactively” to deploy models to the Department of War and the intelligence community, and that it was the first frontier AI company to deploy models in U.S. classified networks and provide custom models for national-security customers. He also said Claude was extensively deployed for intelligence analysis, operational planning, and cyber operations.

The next iteration of the military industrial complex is already taking shape.

In November 2024, Anthropic partnered with Palantir and AWS to provide Claude to U.S. intelligence and defense agencies. TechCrunch reported that Claude would be operationalized inside Palantir’s platform and made available in Palantir’s defense-accredited Impact Level 6 environment, reserved for highly sensitive national-security systems. 

Then Anthropic launched “Claude Gov” which are custom models built exclusively for U.S. national-security customers. Anthropic’s own description says these models were built from government feedback and optimized for classified materials, defense documents, intelligence analysis, and cybersecurity data.

Then came the Pentagon contracts. In July 2025, the Pentagon’s Chief Digital and Artificial Intelligence Office awarded Anthropic, Google, OpenAI, and xAI agreements with $200 million ceilings to accelerate frontier AI adoption across national-security departments. While Anthropic was not alone in line, they have been very deliberately integrating with the government and military at every touchpoint they can access.

But then, earlier this year, the sweetheart deals came to a rupture.

Dario Amodei said, “Disagreeing with the government is the most American thing in the world,” and he paired that with “we are patriots” and “we have stood up for the values of this country.” He was not saying “the Pentagon is immoral, or surveillance is immoral.” He was only drawing two narrow red lines (after the fact, even).

And those red lines are much narrower than the public thinks.

In his statement on the Pentagon dispute, Amodei did not say autonomous weapons are immoral. He said partially autonomous weapons are “vital to the defense of democracy,” and that even fully autonomous weapons “may prove critical” for national defense, but that current frontier models are not reliable enough to power them. He also explicitly supported AI for lawful foreign intelligence and counterintelligence while objecting to mass domestic surveillance.

So the question was not one of morality, only technical ability. His caution was “not yet” not “it’s wrong.”

This distinction matters. Anthropic’s stance is not “AI should not power surveillance or autonomous warfare.” Their stance is closer to, “AI should strengthen the U.S. national-security state, including intelligence and increasingly autonomous warfare, so long as Anthropic can preserve two exceptions—no current fully autonomous kill chain, and no mass domestic surveillance of Americans.”

Anthropic’s primary mistake was trying to litigate military jurisprudence via contract, but make no mistake, they are fully aligned with American exceptionalism and projection of power. 

The Palantir relationship makes the contradiction unavoidable. Palantir was founded by Peter Thiel and Alex Karp with early backing from In-Q-Tel, the CIA’s venture-capital arm, and built its business around intelligence, military, policing, and data-fusion work. In 2026, critics reacted sharply to Palantir’s “Technological Republic” manifesto, which emphasized hard power, the duty of tech companies to participate in defense, and the inevitability of AI weapons.

We need to pause and lampshade an implication here. I am not saying that US military dominance is a bad thing. There are plenty who would. My sole point here is that Anthropic’s behavior is not “fighting for the little guy” or prioritizing civil rights. They are behaviorally no different from any hard-right big-stick war hawk. 

This is where the Thiel comparison becomes useful. Dario Amodei is not Peter Thiel but Anthropic’s worldview is closer to the Thiel/Karp world than its softer branding suggests. Their ideology includes civilizational stakes, sovereign power, strategic competition, elite stewardship, and the conviction that the “right people” must hold the dangerous tools before the wrong people do. And of course, they are the “right stuff” by their own definition. 

Conversely, Sam Altman’s danger is legible. He wants personal power. That’s it. He wants to be important. Money, fame, influence, leverage. Fine. But he’s been totally agnostic about where that comes from. Consider his world tour, where he wanted to build critical AI infrastructure in the middle east, something that would seem unlikely for the “US-first-and-only” values of Karp and Thiel.

Dario Amodei’s danger is subtler. He can explain, in morally serious language, why acquiring power is the responsible thing to do. Not only responsible, but necessary for humanity. And specifically, that he and Anthropic deserve that power. However, when Congress asked Altman “why should we trust you” he flatly said “you shouldn’t.” That was, perhaps, the most honest thing Sam Altman has ever said.

Now, through this belief structure, Anthropic can logically and ethically justify everything from regulatory capture to taking Pentagon money. The ends justify the means, and to spell it out plainly, they believe that advanced AI represents an existential threat to humanity, and so they must be the adults in the room. Well, in order to safely bring ASI into existence, they must be in the driver’s seat. Thus, anything that keeps them in the driver’s seat is fine. It’s a Faustian bargain of ends justifying the means. 

In retrospect, Sam Altman looks like a mercenary who says what he needs to say, mostly for PR and optics reasons. He has spoken grandly about benefitting humanity, but his actions say “so long as I’m in control of OpenAI and I get a seat at the table.” 

Dario, however, seems to be a “true believer” in x-risk and everything else that entails. When he says that AI can kill humanity, it is partly scare-based marketing, but it is also his true worldview. Fear justifies control, which is a playbook as old as civilization itself. 

David Shapiro is the Post-Labor Economics guy, on a mission to liberate humanity from drudgery. He writes at daveshap.substack.com and publishes on YouTube.

The conversation around AI and employment has calcified into two opposing camps. One side predicts a white-collar apocalypse. The other promises frictionless human-machine collaboration. But here's what neither camp seems to discuss: what happens when you're actually inside a Fortune 500 company deploying AI agents right now, today, at scale?

Nancy Xu knows. As Salesforce's AI strategy leader—a role she stepped into after the company acquired her recruiting-focused AI startup Moonhub—Xu sits at an unusual vantage point. She's built vertical-specific agents herself. Now she helps some of the world's largest companies implement them across sales, service, finance, and recruiting.

Her perspective cuts through the noise: this isn't about replacement. It's not even really about augmentation. It's about something more fundamental—a shift in what we mean by "work" itself.

The question isn't whether AI will change jobs. It's whether we're ready to become managers of intelligence rather than executors of tasks.

The Unglamorous Reality of Model Selection

Here's a problem most consumers never think about: when you're an enterprise deploying AI agents, which model should power which task?

It matters more than you'd think. Upgrade to the wrong model version, and you might actually degrade your agent's performance rather than improve it. Deploy a general-purpose model where you need specialized healthcare reasoning, and you've just created an expensive liability.

This is where Xu's team comes in. They run continuous internal benchmarks across OpenAI's latest releases, Anthropic's Claude models, and Google's Gemini, giving customers the confidence that when they upgrade, they're actually upgrading. "A lot of times our customers look to us as a guide for what models they should be using," she explains.

It's tedious, technical work—the kind that doesn't make headlines. But it reveals something crucial about where we are right now: we're not in a one-model-wins-all world. Even within a single platform like Salesforce's Agent Force, customers use a variety of different models. Sometimes the choice comes down to business relationships or cost. Increasingly, though, it's about specialized models trained for specific domains that outperform their general-purpose cousins in particular niches.

The AI landscape is fragmenting, not consolidating. And the companies that win will be those that can orchestrate across this complexity, not those betting everything on a single foundation model.

Everyone Becomes a Director

Ask Xu about her favorite use cases, and she doesn't point to flashy demos or proof-of-concepts. She points to ADCO, a staffing company with a deep partnership with Salesforce.

Here's what's happening there: if you're a candidate communicating with ADCO after business hours today, there's a 50% chance you're talking to an agent. Not a chatbot that routes you to FAQs. An agent that successfully resolves your inquiry—answering questions, updating your status, scheduling next steps.

For Xu, this is the future crystallizing: "I really believe in this vision of making everyone an agent manager. If you're on a customer success team, you can now manage agents. You previously didn't have the resources to delegate the work that you wanted to, and now you can make that possible."

But becoming an agent manager isn't just about offloading tedious tasks. It's about a fundamental cognitive shift—from thinking about the how of work to thinking about the why.

"It's no longer about necessarily all the tactical details of how you do something," Xu explains. "We'll elevate people to think about the why. What are the important strategic things we need to solve? Let me delegate the how to the agents to actually do it for me."

She offers a film production analogy that clarifies the distinction: "If you were on a movie shoot, you were the producer before and now you're the director. It's a different mindset."

The producer handles logistics—scheduling, budgets, resources. The director shapes vision and makes creative decisions. Same project. Different level of abstraction.

Beyond Task Completion

There's a concern lurking beneath the enthusiasm: are we just replacing one form of tedium with another? Instead of manually processing customer inquiries, will we spend our days tediously prompting and correcting agents?

Xu doesn't think so, and her reasoning is tied to where agents are headed. "What does agents look like in one year or two years? I think we're going to move to a world where agents become more long-horizon. They can work on longer objectives, longer tasks for you."

Her example is concrete: "You should be able to tell your agent, 'Hey, I want you to increase my CSAT score by X number of points within 6 months.' And your agent will help you figure that out in simulation with your evals and actually get you to that state."

In that future, the human's job isn't to figure out how to increase the customer satisfaction score—it's to decide that increasing it matters, and to make strategic decisions about the tradeoffs the agent should navigate along the way.

The agent becomes less like a tool and more like a thought partner. Not something you micromanage, but something you direct.

This Time Really Is Different

When asked about labor market disruption, Xu doesn't dismiss the concern. "We do have to acknowledge that work is transforming. A lot of people say the industrial revolution and the farming revolution—those are great analogies, but the truth is AI is moving a lot faster than some of these other previous revolutions."

The speed matters. The industrial revolution gave society generations to adapt. AI is giving us years, maybe less.

But Xu's optimism is grounded not in denial of disruption but in the belief that the transformation can be managed: "Our job is to enable our customers to uplift everyone in their team so that they can become managers of agents."

The companies that thrive won't be those that eliminate headcount most aggressively. They'll be those that successfully transform their workforce from task-executors to agent-orchestrators—people who understand what needs to happen and can effectively direct artificial intelligence to make it happen.

The Trust Layer

As agents take on more consequential work, a thorny question emerges: when something goes wrong, who's responsible?

Xu's answer is refreshingly specific. It depends on the failure mode.

"If it's a copyright issue because your foundational model was trained on a particular type of data, that really sits at the model layer," she explains. "If it's an issue related to, 'Hey, you're not properly anonymizing your end users' information and you're sending it to these third party models without their permission,' that's on the platforms."

This is why Salesforce invested heavily in what they call a "trust layer"—systems that handle data anonymization, access controls, and governance before information ever reaches a third-party model. The most successful agent implementations don't bolt on trust as an afterthought. They design for it from day one.

And they require buy-in at the business level, not just from IT. "The most successful agent implementations we see come from business line leaders who have buy-in," Xu notes. "They're working with the developers, but there's buy-in from the business leaders on what the end goals for the business are."

Translation: if your VP of sales doesn't understand why agents matter and what they're trying to achieve, your expensive AI implementation is probably going to flounder.

How Adoption Actually Happens

How do agents actually spread through organizations? Top-down mandate or grassroots groundswell?

The answer is both—but in different contexts.

Complex agents for service centers or sales operations require centralized, top-down efforts. "It takes a large team effort to build an agent like that," Xu explains. "Usually there's a centralized effort that's building the agent, and then it's about empowering individuals to get on board and use that agent."

But simpler, task-oriented agents—document summarizers, case classifiers—can spread more organically. Xu points to Slack's AI features as an example: "So many people love Slackbot. They use Slack and it's not someone saying, 'Hey, everyone in the organization has to use it.'"

The pattern mirrors previous enterprise software waves: complex systems need executive sponsorship and change management. Lightweight tools can spread virally if they solve real pain points.

The Blurring Boundaries

As agents become more sophisticated, definitional boundaries start to dissolve. Salesforce's Agent Force supports something called A2A—agent-to-agent communication. When one agent calls another agent to complete a subtask, is that one massive agent with sub-agents? Or is that two discrete agents talking to each other?

"I think ultimately the lines become: who are the core platforms that you're using to build your agents and how do they engage with each other," Xu says.

For Salesforce, the strategic bet is clear: build agents that are open, that can communicate with other platforms' agents, and position Salesforce as the orchestration layer. It's a vision of the future that's less about Salesforce-versus-Microsoft-versus-Google and more about creating an interoperable ecosystem where agents from different providers work together seamlessly.

The value shifts from model performance alone to integration, orchestration, and trust. Raw intelligence becomes a commodity. How you deploy it matters more.

What This Actually Means

The future of work isn't humans versus machines. It's humans learning to operate at a higher level of abstraction—defining objectives rather than executing steps, making strategic decisions rather than tactical ones, directing intelligence rather than being the intelligence.

This transition will be faster and more disruptive than previous technological revolutions. But companies like Salesforce are betting the path forward runs through elevation, not elimination. Not replacing workers but transforming them into agent managers.

The question for businesses and individuals alike: are you ready to shift from doing the work to directing it?

Because the agents are here. They're getting more capable by the month. And the role that remains isn't about having all the answers.

It's about knowing which questions to ask.

This article is based on insights from Nancy Xu, AI Strategy Leader at Salesforce and founder of Moonhub, discussing the practical realities of deploying AI agents at enterprise scale.