The Deployment Is The Product
Claude Tag, Unitree, and the Coasean boundary of Hayekian workflows
Introduction
Focusing on what AI is capable of doing and what that implies for both the immediate and the somewhat distant future wasn’t complicated enough for me. And so I decided to read about what Unitree is up to.
You don’t need to click on that link - I can explain what Unitree is in just two words: Galgotiya dog. But the story of how Unitree was born is a fascinating one, and an especially irritating one for Galgotiya:
In 2016, Wang Xingxing, a former employee at DJI, developed a low-cost quadruped robot called XDog for his master’s thesis. He iterated upon the same quadruped in his new company named “Unitree.” For Unitree, their core component of choice was the actuator, the integrated joint that moves the robot’s limbs. Like BYD and their cells, DJI and their flight controller, Unitree chose the expensive actuator (50%-70% of the humanoid BoM) to improve and scale out from.
The rest of the post makes for fascinating reading, especially if you don’t know much about robotics. I certainly didn’t, and therefore enjoyed reading the post in some detail.
But this post isn’t about robotics, the science. It is about robotics, the economics. And the way we’re going to understand it is by linking it to a recent product launch by Anthropic. But let’s begin by trying to answer an important question these days in both AI and robotics.
What, exactly, is the product? (and why is that not the best question to ask?)
What is driving AI adoption inside of firms? Is it the model itself? Or is it the harness?
But in much the same way that it is easier to understand what money is by understanding what money does, it is easier to understand what AI is by what it enables inside the firm.
Many years ago, my first manager in my first job helped me understand how to think about a firm. A firm, he said, has only three functions. It works to increase revenue. Or it works to reduce costs. Or it works to increase speed to market. The rest, this sage said, is just noise.
So rather than get bogged down in terms of understanding what the difference is between the model and the harness, let’s ask rather simpler questions about what AI enables inside a firm. Is it helping reduce costs, increase revenue or increase speed to market? Some combination of these three things? All of these things? And how should one think about the framework one should use while answering these questions?
That’s where Ronald Coase comes in. Take this blogpost, the one you are using right now, as an example of what I’m trying to say. I’ve read each of the articles and papers linked to in this blogpost - with the help of Claude Code and Codex.1 The first draft was read by Codex, and it suggested changes based on my notes in Obsidian. Claude Code ran a second pass. Codex generated the image at the top. I still decide what to write, what to incorporate, what to exclude. I still decide how to phrase a particular sentence, how to write the introduction, and how to frame the conclusion. But a large share of the more mundane parts of my job I can (and do) happily outsource to AI.
If you think of my “job” as being a blogger, a very large number of the “tasks” that make up this job are now done with the help of two harnesses - Claude Code and Codex.
Will AI take your job is the wrong question to ask. How many of the tasks that make up your job can be handed over to AI? That is a better question to ask. And I invite you to spend some time with that question.2
The point is that as a user, you don’t need to bother a whole lot with trying to figure out what the product is. What does AI help you do inside a firm is a better question to ask. And the answer is that it should help you do some of your tasks, and having those tasks be done by AI should:
help you save your firm some costs, or…
help you increase your firm’s revenue, or…
help you increase your firm’s speed-to-market
If these things are not happening, you’re not using AI well. Or worse still, you have not understood what your job at the firm really is for.
So what exactly is the product, then? The model, or the harness? My claim is simple: the agent is not the product, and the robot is not the product. The deployment is the product. AI matters inside firms when it helps stitch isolated tasks into workflows that can be observed, improved, and repeated.
Which brings us to a garbage can.
Ethan Mollick and the Garbage Can
One thing you learn studying (or working in) organizations is that they are all actually a bit of a mess. In fact, one classic organizational theory is actually called the Garbage Can Model. This views organizations as chaotic “garbage cans” where problems, solutions, and decision-makers are dumped in together, and decisions often happen when these elements collide randomly, rather than through a fully rational process. Of course, it is easy to take this view too far - organizations do have structures, decision-makers, and processes that actually matter. It is just that these structures often evolved and were negotiated among people, rather than being carefully designed and well-recorded.
The Garbage Can represents a world where unwritten rules, bespoke knowledge, and complex and undocumented processes are critical. It is this situation that makes AI adoption in organizations difficult, because even though 43% of American workers have used AI at work, they are mostly doing it in informal ways, solving their own work problems. Scaling AI across the enterprise is hard because traditional automation requires clear rules and defined processes; the very things Garbage Can organizations lack. To address the more general issues of AI and work requires careful building of AI-powered systems for specific use cases, mapping out the real processes and making tools to solve the issues that are discovered.
…so don’t feel bad if you realize that you aren’t entirely sure about what your job helps your firm achieve. Often, Ethan’s post helps us understand, the firm itself isn’t quite clear about what your job helps it achieve!
And if you think you have it bad, the robots, they have it worse. Let’s head back to the SemiAnalysis post on robotics and Unitree
Robots: What Are They Good For?
The Semianalysis post talks about Unitree’s robots being used to move bins between two different automation systems:
In this particular job, Agility serves as a “bridge” between automation systems, for example, carrying totes (bins) off the AMRs to place onto conveyor belts. It’s a standard, but particular, logistics workload, where a human typically waits on automation systems to line up for the transfer, but leaving dead time in between.
That’s a simple task, almost painfully simple. But the point isn’t how painfully simple this particular task is. The point is that this robot has gotten cheap enough, and good enough, to be able to reliably do this task inside an actual factory, relative to what a human could do at market rates. Read the rest of the blogpost to understand how Unitree achieved this, how Semianalysis reached this conclusion and what it means for the foreseeable future.
To me, the much more interesting factoid is this one:
There are likely over 250 Unitrees deployed in labor settings today, and we detail how the deployment math works out. Notably, Unitree has made it this far on the back of the small hobbyist/researcher market. Should Unitree unlock viable deployments and hit critical mass, they may accelerate at unreal speed.
The point is that nobody knows right now how to best deploy robots. Unitree doesn’t know it for sure, neither does the firm that is currently using a Unitree robot to carry totes across automated lines. All of us can theorize as much as we want about how it “should be done”, but the only way to find out is by having robots be a part of the workflow, and adjust both the robots and the workflow to each other.
Search, experimentation and discovery, in other words, that helps both the robots and the workflow optimize over time. What is the answer to the question that is being asked in this section? What are robots good for when it comes to firm level economics in 2026?
Here’s my answer: a Hayekian process of discovery is the only way to answer that question, and no amount of central planning is going to get us there. That’s the lesson of the garbage can.
Robots getting cheap enough to do tasks, and reliable enough to do tasks doesn’t just unlock the tasks themselves. That’s a given. It unlocks two very important and perennially underrated things: learning and experimentation. Unitree matters because it may turn physical work into a searchable task space, and not just for Unitree, but for the field at large.
Hayekian processes are unlocked at or below a certain price threshold, and we are beginning to cross that threshold in robotics. Discovery only works when it is cheap enough to get going on that process of discovery!
It helps to understand the flywheel: the cheaper robots get, the more experiments one can run. The more experiments one runs (and AI records), the more learning there is. The more learning there is, the higher the feedback flowing back to Unitree. Plus, more (and faster!) optimization of workflows. This enables robots to become better and cheaper, allowing more experiments to be run.
Rinse, and repeat.
This is worth reiterating: this is made possible by having this flywheel spin, and this flywheel spins faster because AI sits at the boundary of many different tasks that together make up this workflow. An automated system does one thing, a robot picks up that thing and transfers it to another automated system, which does another thing, and this continues until the product is fully manufactured. Once AI is able to observe the whole thing, and how handoffs occur at different phases, it will be able to optimize the process, and provide feedback to all parts of the process, making the entire system better.
And that is how one should understand Claude Tag.
What is Claude Tag?
Claude Tag is Anthropic’s Slack-native version of Claude. You tag Claude in a Slack channel, give it access to selected tools and context, and delegate work to it inside the team’s normal flow of conversation. You may think it is “just a bot” inside Slack, but that would be missing the point.
But you’re missing the point if you think of it as a “bot” inside Slack. Think of it, instead, as the enablement of a faster flywheel, but for software related workflows. In much the same way that the flywheel will work for robotics, Claude Tag will now not just do your tasks, but will also understand how that task fits into your workflows… and across many different employees who are going to be associated with that workflow.
It is now not just getting context about what you do and how you do whatever it is do. It is now getting to understand how what you do fits inside what the rest of your team/department/organization is supposed to be doing.
The garbage can may not disappear. But for the first time, it may become visible enough to be worked on.
TMKK?
Go back to the title of this blogpost, and think about what both Unitree and Claude Tag are enabling. They’re now figuring out how to deploy experimentation with AI and robotics within and across individual workflows. Claude Tag and Unitree make coordination cheaper, but they do not decide what is worth doing. That can only come from the process of experimentation. But they help to unlock that process, and that is of crucial importance.
Claude Tag and Unitree don't just do tasks. They collapse the cost of coordinating between tasks. The task isn’t the job, yes. But it is more complicated than that. Someone needs to stitch many different tasks together in a way that is reasonably cheap, verifiable and leads to economic benefits for the firm. That's a transaction cost, no? Notice the difference between two questions and how they both apply here. Coase tells you why the boundary moves across many different tasks when coordination gets cheap. Hayek tells you how you find the better arrangement once it does. YOu do it through cheap, distributed experimentation. Why? Because nobody can plan their way to the right workflow from a top-down perspective.
The deployment is the product then, but not at the level of the individual worker. Today, it is deployment at the level of the workflow. Tomorrow, it will be at the level of multiple workflows, and across hierarchies. As Roon would put it, the models, they’re now thinking one level up.
I have a skill called Chautauqua, which I use to have a conversation with some of the articles that I save. Both Claude Code and Codex use the Obsidian CLI to help me save articles, backlink them, and they help me keep my Zettelkasten system updated. If any or all of this sounds confusing, ask your LLM of choice about it.
Whether you sit with that question, or stand with it, or walk with it is entirely up to you. If you are looking for recommendations, I would suggest having a cup of coffee with it.