That idea helped agents move beyond answering questions. An agent can now use tools to search, read, write, and complete work.

They can search for a product, book a trip, check an order, fill out a form, and update an account. Much of this work still happens the hard way. The AI looks at a website, guesses what each button means, clicks around, and tries to recover when the page does not behave as expected.

Check out my previous articles and do subscribe to keep yourself updated on the latest happenings in the world of AI

Subscribe now

WebMCP is an attempt to make that process clearer.

It gives a website a way to tell an AI agent what the website can do. The agent can use named actions such as get_order_status or create_support_request. It does not have to guess from the page layout alone.

A website that is easier for AI to use may give customers faster service, fewer steps, and a better way to complete complex tasks.

This article explains what WebMCP is, how it works, how to build a small example, and where it may matter for a business.

Short version: WebMCP helps an AI agent use the website that is already open. MCP usually connects AI to backend systems. They solve different problems and can work together.

Who Created WebMCP? W3C, Google, and Microsoft

WebMCP is not an OpenAI-only technology. It is an experimental proposal being developed in the W3C Web Machine Learning Community Group.

The current WebMCP editors listed in the specification are:

• Brandon Walderman from Microsoft

• Khushal Sagar from Google

• Dominic Farolino from Google

The public design discussion was already active in September 2025. The work is still a draft, not a finished web standard. Chrome announced an early preview on February 10, 2026, and published its WebMCP documentation in May 2026.

The WebMCP specification, WebMCP GitHub repository, and Chrome early preview announcement are the best places to follow the work.

WebMCP Explained in Simple Terms

WebMCP is a proposed browser standard. It lets a website describe actions that a browser-based AI agent can use.

The website supplies four things:

• A name for the action

• A short explanation

• The information the action needs

• The website code that runs the action

  

Example, a support website might expose this action:

Name: get_order_status
Purpose: Return the current status and delivery estimate for an order.
Input: orderId
Result: status, estimated delivery, explanation

The customer can still use the website normally. The page keeps its design, login session, and current information. A compatible AI agent gets a clearer way to use the product.

The main consumer of these tools is the agent. The person remains the decision-maker.

Why WebMCP Matters for Businesses

WebMCP is interesting because it connects AI to the product experience that already exists.

The human does not disappear from the journey. The agent handles the search, form filling, and repetitive steps. The person supplies intent, judgment, and approval.

That can matter in four areas:

Reduce Customer Effort with WebMCP

Some tasks are simple in theory but tiring in practice. A customer may need to open several pages, find the right order, choose a category, enter the same information again, and wait for a result.

An AI agent can help. The problem is that ordinary browser automation often makes the agent work like a person with a blindfold. It has to infer the meaning of the page from text, buttons, and layout.

WebMCP gives the agent a direct path to the product action.

Lower Customer Support Costs with WebMCP

Support teams spend time on tasks such as checking an order, finding a policy, changing an address, and preparing a ticket.

WebMCP does not remove the support team. It can help the customer find the right answer and prepare a better request before a human takes over.

That can reduce repeated questions and improve the quality of the first support message.

Improve Conversion and Task Completion

Every extra step creates a chance for a customer to drop.

This matters in travel booking, applications, checkout, insurance claims, onboarding, and other long forms. An agent that can use the product directly may help more customers finish the task.

A business should measure completion rate, customer satisfaction, support contacts, and errors before claiming an improvement.

Build Customer Trust and Control

The best agent experience is not invisible automation. The customer should see what is happening and approve important actions.

WebMCP keeps the page in the browser. A website can show the current state, highlight the action, and ask the customer to confirm before a purchase, message, or account change.

Subscribe now

WebMCP Example: Before and After

Imagine a customer says:

“Find my delayed order, explain what happened, and open a support request.”

How Browser Automation Works Without WebMCP

The AI may need to:

1. Read the page and find the order area.

2. Guess which control opens order tracking.

3. Enter an order number.

4. Click a button.

5. Wait for a page update.

6. Read the new page.

7. Find the support form.

8. Copy information into the form.

9. Submit or ask the customer to submit it.

The flow can work. It depends on the page layout and the AI’s guesses.

How WebMCP Makes Website Tasks Easier

The website can expose three actions:

1. get_order_status(orderId)

2. search_help_articles(query)

3. create_support_request(orderId, issue, email)

The AI can use the first action to check the order. It can search the help content next. It can prepare the support request and stop for customer approval before the final action.

The customer still sees the page. The business still owns the rules. The AI has a clearer way to use the product.

Real WebMCP tool in the OpenAI’s demo - Margin Editor

WebMCP Demo: Build Agent-Ready Websites

The best way to see the idea is OpenAI’s short video, Build agent-ready sites with WebMCP.

How the WebMCP Architecture Works

The WebMCP flow is short:

Customer asks for something
          ↓
AI agent understands the request
          ↓
Browser finds the website’s available actions
          ↓
AI sends named action + input
          ↓
Website runs its existing product logic
          ↓
Page updates and returns a result
          ↓
Customer sees the result and approves important actions

The browser sits in the middle. The page exposes selected actions, and the browser controls access to them.

The page keeps its current state and login session. The tool can call the same client code that a button uses. That reduces the need to build a second version of the product only for AI.

The official WebMCP repository describes this lifecycle as registration, discovery, invocation, execution, and response. The WebMCP repository has the current explainer and implementation details.

WebMCP vs. MCP vs. Browser Automation

These words are a bit confusing.

What Is Browser Automation?

The AI looks at a website and clicks or types. This is useful for many sites today. It can also be fragile because the AI has to guess what each control means.

What Is WebMCP?

The website tells a browser agent about the actions it supports. The actions live close to the page and its current state.

What Is MCP?

MCP usually connects an AI system to backend tools and data. It works well for tasks that do not need a visible website or a specific browser session.

When to Use WebMCP, MCP, or Browser Automation

These tools solve different problems. The right choice depends on where the work happens and how much control the customer needs.

WebMCP, MCP, and Browser Automation Comparison

WebMCP: A person has your website open and an agent needs to use the live page, current session, and visible product state

Example: Check an order, fill a support form, configure a product, or edit a document together

MCP: An agent needs access to backend data or business actions from many places, without opening the website

Example: Search inventory, read account data, create an invoice, or run a background workflow

Browser Use or similar browser automation: You need an agent to work with an existing website that does not expose structured tools

Example: Use a legacy admin panel, collect information from several sites, or complete a task on a third-party website

Browser Use is often the fastest way to automate a site you do not own. WebMCP is the better long-term interface when you own the product and want agents to use it reliably.

How Businesses Can Combine WebMCP, MCP, and Browser Automation

MCP can hold the core business capability. WebMCP can connect that capability to the live customer experience. Browser automation can cover systems that are outside your control.

OpenAI’s WebMCP Challenge and Real-World Demos

OpenAI is organizing a challenge. OpenAI’s WebMCP Challenge asks builders to explore what becomes possible when people and agents use the web together.

The challenge page includes these demos:

• 3D Modeling - build and refine a 3D model while watching the scene change.

• Collaborative Writing - write and revise in a shared document where the agent can leave comments.

• Crossword Builder - create and refine a crossword around a topic.

• Wandernote - turn travel notes into an itinerary and shape it together.

• Data Exploration - query data with DuckDB-Wasm and create visualizations in the browser.

The OpenAI Developers WebMCP showcase adds more examples, including Fieldwork, WanderNote, Sunday Table, Paperie, Webroom, Verdant Market, Crossword Desk, and Codex Modeling Studio.

OpenAI describes site tools in the ChatGPT desktop app as a way for ChatGPT to use tools exposed by the website open in its built-in browser. The tools are available while that page is open.

Read Using site tools in the ChatGPT desktop app.

What WebMCP Does Not Solve

WebMCP is useful, but it is not a complete agent strategy.

It does not replace:

• Login and identity checks

• Server-side permissions

• Business rules

• APIs

• Backend MCP tools

• Human approval for sensitive actions

• Monitoring and support processes

• Testing and evaluation

It also does not make every website agent-ready overnight. The product still needs clear actions, sensible limits, useful results, and a good customer journey.

The Future of AI-Ready Websites

WebMCP points to a change in product design.

For years, teams designed websites mainly for people. They focused on navigation, labels, forms, and visual hierarchy.

Those things still matter. Now teams also need to decide how an AI agent should understand the product and help a customer use it.

The best website is the one that works well for both people and AI.

WebMCP is an early step in that direction. It may reduce the gap between what a product can do and what an AI agent can reliably help a customer do.

For a founder or product manager, the practical question is simple:

Which important customer task is harder than it needs to be, and could a clear AI action make it easier without taking control away from the customer?

This is Part 3 of the Sovereign Enterprise series, based on Eric Gilmore’s blueprint for companies that own their AI rather than rent it. Part 1 covered Sovereign Intelligence, the company’s digital brain. Part 2 covered the Sovereign Workforce, digital workers with names, permissions, and employment records. This article covers Sovereign Infrastructure.

Consider the outdoor-gear retailer from the earlier articles. Its company brain knows that John bought a tent yesterday, returned a sleeping bag last week, and complained about shipping a month ago. The retailer’s Digital Twin knows the warehouse has 1,240 tents and 38 late orders. When an agent almost sent John a 99% discount instead of 20%, the Control Plane stopped it.

Right now, all of it runs on someone else’s computers.

Imagine spending two years building your dream house. The interior is beautiful and the design is yours. But the land is not yours it’s landlords’. Every year you stay, moving out becomes more expensive.

Here, the infrastructure is the land. The landlords are the hyperscalers: Amazon, Microsoft, and Google, which run much of the internet.

I am not saying you should leave the cloud. Use the big providers as suppliers you can replace, not as the foundation that defines your company. The goal is to keep your options open.

You can check out my previous articles:

Subscribe now

The Hyperscaler Trap: AI Infrastructure Lock-In

Each part of this series has had a trap.

In Part 1, we looked at companies that rent their thinking by using someone else’s AI and sharing their knowledge.

In Part 2, we looked at the Augmentation Trap: adding a few copilots and calling the company AI-powered.

This is the third trap: the Hyperscaler Trap, mentioned in the paper. It is the belief that you can rent the infrastructure your AI depends on without losing control.

A web app on a rented computer is still fine. Your ontology, knowledge graph, AI memories, and evaluation records are different. They are part of your company’s mind. But now they are stored on a rented computer as well.

Lock-in grows step by step. The model runs on the provider’s platform. The vector database comes from its catalog. Each new app uses the same provider’s tools. Over time, the company stops choosing its own architecture.

Nothing dramatic happens at first. Moving becomes more expensive, and your team slowly loses the skills needed to do it. Eventually, the cloud bill becomes a dependency.

A dependency is only comfortable while the terms stay the same. They don't.

Cloud Terms Can Change: AI Data and Model Risk

Here are a few changes that are happening recently.

• Starting September 9, 2026, Lovable may use Free and Pro users’ projects and prompts to train its models.

• GitHub uses Copilot interaction data from Free, Pro, and Pro+ users for training by default and may share it with Microsoft affiliates.

Both services offer opt-outs and exclude Business and Enterprise plans.

• In August 2025, Anthropic changed its consumer terms to allow chat data to be used for training unless users opted out; Business plans were excluded.

• Providers can revoke access: Anthropic suspended OpenAI’s API access after a terms violation.

• In June 2026, Anthropic disabled its newest models worldwide after a U.S. Commerce Department export-control letter.

Companies and governments can shut off AI access, even for paying customers. Providers can change their terms, and cheaper plans generally offer fewer protections.

If your data is deeply integrated into a provider’s systems, moving it later may be difficult and expensive.

Cloud Egress Costs and Data Portability

A dependency remains manageable only as long as the terms remain unchanged. However, they do not.

Moving data into the cloud is cheap. Keeping it there is cheap too. Moving it out costs more. Providers charge for egress and for moving data between regions or clouds. The paper calls this a one-way valve: “data flows in cheaply, accumulates quietly over years, and becomes increasingly expensive to move.”

Now imagine doing this for six years. You are locked into their ecosystem. Your most valuable asset quietly becomes your least mobile one.

The Five Planes of AI Infrastructure

Let’s look at the layer below the digital brain. In Part 1, we broke the brain into five planes. Infrastructure has five planes as well.

The Compute Plane is processing power: CPUs, GPUs, inference clusters, and training environments.

The Data Plane is long-term memory. It includes object storage, databases, analytical tables, and metadata catalogs. This is where the knowledge graph lives.

The Runtime Plane is where software runs. It includes containers, orchestration, model serving, agent runtimes, and the software factory from Part 2.

The Network and Deployment Plane controls where systems run. It includes regions, clouds, on-premise clusters, and failover. It keeps you from being “trapped in one location, one provider, or one deployment model.”

The Infrastructure Control Plane manages cost, policy, security, workload placement, and your ability to leave. It plays the same role as the Control Plane that blocked John’s 99% discount, but one level lower.

The five planes tell you what you own. They don't tell you how to own it.discover

Four Rules for Sovereign AI Infrastructure

What does ownership look like?

Use open foundations.

Choose tools that work in more than one place: Kubernetes for containers, Postgres for relational data, the S3 API for object storage, and Parquet or Iceberg for analytical tables. Use OpenTelemetry for monitoring and open model weights when possible. As the paper says, “These are not merely technology preferences. They are sovereignty commitments.”

Keep the valve open in both directions.

Store data in open formats and keep the metadata portable. That way, the meaning of the data survives a move. Estimate the cost of leaving on day one, while it is still cheap to plan for.

Use managed services carefully.

They are often useful and often the right choice. The risk comes when a service is both very convenient and difficult to replace. Before adopting one, ask whether its API and data model work elsewhere. A small dependency may be fine. A dependency at the center of your company’s ontology is much riskier.

Treat compute like electricity.

An industrial company can buy power from several suppliers through standard connections. It can shift demand when prices change. Compute should work the same way. You should be able to select and switch whoever provides the best service, price etc.

Every major infrastructure decision should answer one question: “what would it cost to leave?”

You do not have to leave. The ability to leave is what changes the balance of power.

The Sovereign Enterprise Blueprint

Let’s put it all together.

The blueprint is simple.

• An ontology defines what your words mean.

• A knowledge graph stores what your company knows.

• A Digital Twin represents the present, while a

• World Model prepares for the future.

• Humans and digital workers follow the same rules, with autonomy earned over time.

• A software factory turns intent into code, while a

• Control Plane governs the process.

• Underneath it all are five infrastructure planes built on open foundations.

Gilmore’s closing cadence:

Starting today, make your choices wisely; start becoming a Sovereign Enterprise

References

[1] Eric Gilmore. “The Sovereign Enterprise: A Blueprint for the Cognitive Revolution.” - sovereignenterprise.org. July 2026.

[2] The Tool Nerd. “The Sovereign Enterprise — Part 1: Why Renting AI Will Break Your Business.”

[3] The Tool Nerd. “The Sovereign Enterprise — Part 2: Your Next Hire Won’t Be Human.”

[4] Lovable. “Data opt-out.”

[5] GitHub Blog. “Updates to GitHub Copilot interaction data usage policy.”

[6] TechCrunch. “Anthropic users face a new choice: opt out or share your data for AI training.”

[7] TechCrunch. “Anthropic cuts off OpenAI’s access to its Claude models.”

[8] CSIS. “Department of Commerce Restricted Access to Anthropic’s Latest Models: What Comes Next.”

That assumption is breaking now. This post is about what replaces it.

This is Part 2 of a three-part series on the Sovereign Enterprise, Eric Gilmore’s blueprint for companies that own their AI rather than rent it [1]. Part 1 covered the first pillar, Sovereign Intelligence. It explained why renting your thinking is a trap, what an ontology is, and the five planes of a digital brain your company owns. New here? Start with Part 1. This post builds on it.

The recap fits in one line:

Sovereign Enterprise = Sovereign Intelligence + Sovereign Workforce + Sovereign Infrastructure.

Part 1 was the brain. Today it is the workforce: who does the work when some of your employees aren’t people.

Subscribe now

The Enterprise World Model: Moving Beyond Systems of Record

Before the workforce, I owe you something. Part 1 ended with a teaser about the World Model. Here’s where it fits.

Think of it as three layers. Each layer answers one question.

The Ontology answers: What does this mean? That’s the dictionary from Part 1.

The Digital Twin answers: What’s happening right now? It’s a live replica of the company. Google Maps is the best analogy I know. The map isn’t the road, but it shows the real traffic on the road this minute. The Digital Twin does the same for your business.

The World Model answers: what happens next if we act? It takes the current state from the Digital Twin and runs what-if scenarios on it.

Gilmore compresses all three into one line:

The last era of software gave us systems of record. A system of record can only tell you what already happened.

The next era runs on all three layers: an ontology for what things mean, a Digital Twin for what’s true now, and a World Model for what may happen next.

One connection back to Part 1 before we move on. Where does the Digital Twin keep all this state?

In the knowledge graph — the ontology filled in with live facts. And the graph remembers more than a database does. It knows when each fact became true, who asserted it, and how it changed over time. So, the graph holds what the company knows, and the World Model plays that knowledge forward. Memory and imagination work as a pair.

In practice, our retailer could test a price change on thousands of simulated customers before trying it on one real one. It could stress-test its supply chain against a failure that hasn’t happened yet. It could rehearse a bad quarter without living through it. Gilmore calls this the flight simulator of the enterprise. I haven’t found a better name. Pilots don’t learn when there are real passengers on the flight; they learn with simulation first.

That’s the last piece of the brain we built in Part 1. Now for the real subject of this post: the workforce that uses it.

Gilmore calls it,

Sovereign Workforce: one workforce made of human and digital workers, run under the same rules, and owned by the company itself.

Check out my previous articles here.

Subscribe now

The Sovereign Workforce: Unifying Human and Digital Teams

So let’s meet the new kind of worker.

It takes an instruction, holds the context, applies judgment, produces an output, accepts feedback, and gets better over time.

For the first time in industrial history, there’s a category of worker that isn’t a person.

They budget them as tools, govern them through IT, and measure them in minutes saved. This is how early industrialists were treating steam engines, as bigger water wheels. They weren’t able to see the bigger change that was coming by.

The AI Augmentation Trap: Why Copilots Aren’t an AI Strategy

Look at how most companies adopt AI today. A copilot in the developer’s editor. A summarizer in the analyst’s inbox. A drafting assistant for marketing. Vendors call this augmentation. It feels like an AI strategy:

This is called the Augmentation Trap. The trap is subtle because the benefits are real. Replies do go out faster. Drafts do take less time. But the gains are local, and they don’t compound. You end up becoming tool-rich but architecture-poor. Plenty of AI features, but the company still runs on human-era assumptions about jobs, departments, and approvals.

Picture two versions of our retailer. One gives its support staff an email copilot. Every reply gets two minutes faster, and that’s where it ends.

The other builds a support agent: a digital worker with a name, defined permissions, and a track record. The agent resolves the routine half of the tickets end-to-end. Humans handle the hard half.

A year later, the first retailer has faster humans. The second has a bigger workforce.

Treat Digital Workers Like Employees

In a Sovereign Workforce, every digital worker gets what any human employee has. An identity: a name, an owner, a defined job, a set of permissions.
A capability profile: its skills, and how good it has proven to be at each one.

That’s like a resume the company can verify, because every past task is on record. And accountability: every action is logged with its reason. When something goes wrong, you can reconstruct what happened and who authorized it.

Remember the moment in Part 1 when an agent tried to send John a 99% discount and the Control Plane blocked it?

In a Sovereign Workforce, that agent has an employment file. The incident goes in it. Its autonomy on discounts gets dialed down. A human reviews its next fifty sends. It earns the trust back with a clean record.

There’s one more idea here I find quietly radical: work is never assigned to humans or machines as a yes/no choice. It sits on a dial.

New agents start supervised. Proven agents earn autonomy. Struggling ones get pulled back. Exactly like people.

The unit of work changes too. It stops being the individual and becomes the team — usually a mixed one. Humans and agents assemble around an objective, then dissolve when it’s done.

That’s the whole checklist, by the way. Gilmore calls these the five properties of a Sovereign Workforce: identity, capability, the continuum, accountability, and composability.

One more piece makes the routing work. The work itself gets broken down — from company vision, through goals and processes, all the way to a single task. Each task carries enough definition that any qualified worker can pick it up.

Measuring Hybrid Output: The Work Points Framework

A hybrid workforce creates an odd new problem: how do you measure work when the workers are this different? Hours measure duration, not difficulty. Headcount measures people, not work.

Gilmore’s answer is Work Points. The paper defines work as a multidimensional demand profile: every task gets scored on seven dimensions.

• Effort is how much labor there is, regardless of how hard it is.

• Complexity is how difficult it is to understand and execute.

• Uncertainty is how much is unknown going in.

• Coordination is how many people and systems must align to finish.

• Risk is how badly failure would hurt.

• Variability is how much the task changes from case to case.

• Expertise is the specialized knowledge it takes to do it well — a task can be simple for an expert and impossible for a generalist.

Seven numbers instead of one, and the shape they make is the point. The paper’s own example: two tasks both score 75 Work Points, but one is dominated by risk and expertise while the other is dominated by effort and coordination. Treat them as the same task and you’ve made a management error. Score them properly and “who should do this?” stops being a turf war. It becomes a routing decision.

• High-effort, low-complexity work goes to agents.

• High-risk calls stay with senior humans.

• The messy middle goes to mixed teams. And every completed task sharpens the record of who does what best.

The AI Software Factory: Scaling Agentic Engineering

Where does this hybrid workforce show up first? Software.

The argument: software is how a modern company encodes itself — its processes, its policies, its products. So if you own your intelligence, you must also own the machinery that turns intelligence into software. Not a coding assistant.

A software factory: fleets of specialized agents that build, test, review, document, and deploy. They work under encoded standards. Humans define the intent and judge the results. And before anything ships, it runs against the World Model. The flight simulator again — this time as the factory’s test track.

The human engineer doesn’t disappear. The job moves up a level. Less typing on every line. More deciding what should exist, directing the agents that build it, and judging what they produce. Gilmore names the discipline agentic engineering. My shorter version: the engineer stops being the factory and starts running one.

So what’s inside this factory? Gilmore lists six components. I find them easier to picture as rooms in one building.

• The agent fleet is the workers.

• Orchestration is the shop floor that splits intent into tasks.

• Evaluation is the quality gate.

• Delivery is the loading dock.

• Governance is the rulebook.

• And the integration room wires the whole building into the brain from Part 1 — the ontology, the memory, the simulator. Intent walks in one door. Governed software walks out the other.

Building Enterprise Moats with an Owned AI Workforce

A productivity feature delivers its gain once. A Sovereign Workforce learns.

Every completed task sharpens the record: which workers handle what best, where autonomy is safe, where human judgment stays non-negotiable. Run that loop for five years. You now know things about running a hybrid workforce that a competitor can’t buy, because the knowledge only comes from running one.

The workforce is going hybrid either way. The only question is whether yours will be designed or accidental.

Part 3 closes the series with the ground all of this stands on: Sovereign Infrastructure. Why the hyperscalers are the last landlords, and what owning your foundations actually takes.

References

[1] Eric Gilmore. “The Sovereign Enterprise: A Blueprint for the Cognitive Revolution.” sovereignenterprise.org. July 2026.

[2] The Tool Nerd. “The Sovereign Enterprise — Part 1: Why Renting AI Will Break Your Business.”

AI can make your company faster. But if someone else owns the intelligence behind every decision, what exactly do you own?

If you run a business today, chances are AI is already doing a lot of your work. Writing, coding, marketing, sales follow-ups, automation. It feels like the smart, efficient way to operate. It’s also, quietly, a trap.

The software you bought in the past was never your intelligence. It was a commodity, and renting it cost you nothing strategically. AI is different. AI is intelligence, and intelligence is the foundation of a business. When you rent it, you’re renting the one thing you’re supposed to own.

So if you’re running your company on someone else’s intelligence, and sharing all your knowledge with them along the way, you’re not building a resilient business. You’re renting space in someone else’s empire.

That’s the core argument of The Sovereign Enterprise, a paper Eric Gilmore published recently that I’ve been chewing on ever since.

A Sovereign Enterprise is a company that owns its data, its meaning, its models, and its automated workers, and refuses to pay the hidden cost of renting intelligence from a third party.

Gilmore’s blueprint rests on three pillars:

Sovereign Enterprise = Sovereign Intelligence + Sovereign Workforce + Sovereign Infrastructure

In plain terms: a brain the company owns, digital workers the company controls, and infrastructure that runs on the company’s own terms. Each pillar is a big enough topic that cramming all three into a single post would shortchange them, so this series covers them one at a time.

Today is the brain — Sovereign Intelligence. We’ll look at why the current AI landscape is uniquely dangerous for businesses, what an ontology actually is, and how you give your company a mind of its own.

Subscribe now

The Outsourcing Trap

When you build your operations on generic models like Claude or GPT, the way you write content, analyse data, and run operations starts to bend around the intelligence they provide. At first this feels great. You’re moving fast. Then one day you notice you can’t do any of it without them.

One thing you need to know: this isn’t like the cloud. When you use AWS or Azure, you still own your data and your logic. You’re just renting machines. With AI, you’re transferring the knowledge itself, knowledge that used to live entirely inside your company, into an external model. The same knowledge that could eventually be turned around on your own industry.

If you don’t own the intelligence that runs your company, you lose your edge. The paper suggests that a business has to establish control across five areas: data, meaning, models, software, and automated workers.

But owning those assets isn’t enough by itself. The five sovereignties define what the enterprise must own. Sovereign Intelligence defines how that ownership becomes operational.

Sovereign Intelligence: The Digital Brain

Sovereign Intelligence is the enterprise’s owned system of cognition. That may sound like a lot, so here’s the simple version: it’s the architecture that brings your data, semantics, models, software, agents, and governance together into one living system your company can control, improve, and trust.

It connects what the company knows to how it understands, reasons, decides, acts, and learns.

Fragmented data becomes knowledge, knowledge becomes judgment, judgment becomes coordinated action, and action becomes learning that stays inside the company instead of leaking out to a vendor.

Before we look at how this brain is structured, though, we need the foundation it runs on: the Ontology.

What’s an Ontology?

An ontology is a machine-readable map of how your business operates. It defines the entities (customers, products, orders), the relationships between them (customers place orders, orders contain products), and the rules that govern them (an order can’t ship until payment clears).

Picture an e-commerce company. Its ontology looks like a massive, interconnected web of logic covering everything the business touches: who your customers are, what they ordered, how it gets paid for and shipped, and every rule connecting those pieces.

Ask any chatbot to "find all delayed orders" and watch what happens. It answers. Confidently. But delayed by what standard? The model has no idea where your business draws that line, so it invents something reasonable-sounding and moves on. An ontology is where you draw the line yourself. Write down that delayed means no delivery scan within 48 hours of the promised date. The AI model works from a rule you wrote, an SOP you have defined.

This is also why renting intelligence is a trap. You can’t build a true Enterprise Ontology inside someone else’s closed system.

The meaning of your business has to be yours.

Subscribe now

You’ve Already Used an Ontology Today

If “ontology” still sounds like an academic word, here’s the thing: you’ve been on the receiving end of one for years.

Those info boxes beside Google search results came from the Knowledge Graph, and the name is the giveaway: take an ontology of people, places, and things, fill it with billions of real facts, and what you get is a knowledge graph.

Netflix runs its catalog and recommendations on an internal content ontology. Amazon’s product graph is the same idea pointed at shopping. Doctors around the world record diagnoses in SNOMED CT, a shared medical vocabulary, so “heart attack” means the same thing in every hospital system.

And Palantir built its entire Foundry platform around an enterprise ontology — probably the closest existing thing to what Gilmore describes.

So the concept isn’t new. What’s new is that AI finally makes it worth building one for a normal-sized business — because now the map has a reader.

The Five Planes of Intelligence - Sovereign Intelligence

Once you have your ontology, you can organize the company’s brain across five interdependent planes. Here’s how our e-commerce retailer would structure it.

1. The Semantic Plane (The Foundation)

This is where the entire Enterprise Ontology lives, along with all the business rules, taxonomies, and logic that give coherence to everything the company knows, observes, builds, and executes. The question this plane answers: what does this mean, and how does it relate to everything else?

For our retailer, the Semantic Plane pins down exactly what a “Customer” is. It says a VIP Customer is anyone who’s spent over $500 in the past year, and a Churn Risk is anyone who hasn’t opened an email in six months. When an AI agent looks at a record, it gets the business context, not a bare row of data.

2. The Knowledge Plane (The Reality)

The Knowledge Plane sits above the Semantic Plane. If the Semantic Plane defines what things mean, the Knowledge Plane tracks what’s actually true, and preserves the memory of it: entities, events, documents, transactions, telemetry, all continuously updated.

It’s a living record. At any point you know the current state of the whole organisation, plus how each fact got there: when it was established, why it changed, and what the company learned from it. As autonomous systems take on more of the work, that traceability stops being a nice-to-have.

In practice, this plane gets built as a knowledge graph: the ontology populated with reality. Every actual customer, order, payment, and return becomes a connected, queryable fact. It’s the same concept as Google’s Knowledge Graph from earlier — just pointed at your business instead of the whole internet.

For the retailer, this is the unified memory that knows John bought a tent yesterday, returned a sleeping bag last week, and complained about shipping times a month ago. No guessing. The reality is on file.

3. The Cognitive Plane (The Reasoning)

This is the reasoning layer, home to the enterprise’s own tailor-made, fine-tuned domain models.

No single model architecture or reasoning strategy rules it all. Predicting what a customer will do next is a different job from working out why something happened or from weighing which fix is worth the money. So this plane keeps several kinds of reasoning on hand, gives each question to the one that fits, and tracks which ones actually earn their keep.

For our retailer, this is the layer that takes John’s history (Knowledge Plane), sees he’s a VIP Customer (Semantic Plane), and reasons that a 20% discount on hiking boots is the best way to keep his loyalty.

4. The Agentic Plane (The Action)

Where reasoning becomes work. This plane holds the autonomous and semi-autonomous agents that observe, reason over objectives, make decisions, and act.

For the retailer, it’s the digital worker that actually sends John the personalized discount email, updates the marketing dashboard, and alerts the warehouse to prepare for a potential boot order.

5. The Control Plane (The Governance)

The final plane, and the one everything else depends on. The Control Plane makes the whole system governable, auditable, secure, and enterprise-grade.

It governs meaning in the Semantic Plane, truth in the Knowledge Plane, reasoning in the Cognitive Plane, and action across the Agentic Plane. If an agent tries to send John a 99% discount by mistake, this is the layer that catches it, flags the error, and stops the send.

The Brain Doesn’t Stop There

One honest caveat before we close: the five planes are the skeleton of the digital brain, not the whole of it. Gilmore’s paper goes further — into the knowledge graph we just met, an Enterprise Digital Twin that mirrors the live state of your company, and a World Model that turns the whole thing into what he calls a flight simulator of the enterprise.

Imagine testing a price change against thousands of simulated customer reactions before trying it on a single real one.

That last idea deserves its own post, because it quietly flips what AI is for. Most business AI today does retrieval: finding what you already know. A World Model does simulation: reasoning about what hasn’t happened yet. As Gilmore puts it, the winner won’t be the company that reacts fastest to reality, but the one that learns to predict it. We’ll dig into that later in this series.

Most business AI today does retrieval. A World Model does simulation.

The Choice Ahead

If you want to survive the Cognitive Revolution, you can’t rent your reasoning.

Own your ontology.
Control your knowledge.
Govern your agents.

In Part 2, we’ll go deeper into the Agentic Plane: how a Sovereign Workforce operates, and why building your own digital employees is the only way to scale without losing control.

References

Eric Gilmore. “The Sovereign Enterprise: A Blueprint for the Cognitive Revolution.” sovereignenterprise.org. July 2026.

Google. “About Knowledge Graph and Knowledge Panels.”

Netflix Technology Blog. “Unlocking Entertainment Intelligence with Knowledge Graph.”

Palantir Build.

SNOMED CT Practical Guides. “SNOMED CT Logical Model.”

Buzz takes a different route from Slack, Discord, or most AI tools.

Before you create a channel, it asks you to create an identity key. Before you invite people, it asks you to connect that identity to a community. And before an AI agent can help, it gets its own profile, permissions, and model settings.

That can feel like a lot on day one. I felt the same way while setting up the first TheToolNerd community. This guide shows every screen in the order I saw it, with plain-English explanations of what to click and why it matters.

By the end, you will have a Buzz community, a personal profile, and a starter team of AI agents ready to work in channels with you.

Check out my previous articles

Subscribe now

The “Normal User” Reality Check

Before we dive in, let’s be honest: Buzz is promising, but it is not yet ready for the average user.

If you are looking for a simple “plug and play” experience like Slack or ChatGPT, you might find Buzz frustrating. The setup is not easy, and the underlying concepts — like cryptographic keys and relays — can be confusing. It is currently in an early alpha/beta stage, which means you will hit bugs, and things won’t always work the first time.

Is it worth the effort? If you are a developer, a technical founder, or someone who loves being on the bleeding edge of AI, yes. If you just want a tool that “just works” without a technical learning curve, you might want to wait a few months for the product to mature.

Why Jack Dorsey and Block are Building Buzz: The Vision Behind the Tool

Buzz.xyz isn’t just another startup project; it’s a direct product of Jack Dorsey’s evolving vision for the internet. Dorsey, the co-founder of Twitter and current head of Block, has shifted his focus entirely toward decentralized, open-source protocols. Buzz is the latest, and perhaps most significant, manifestation of this shift.

By building directly on Nostr—a protocol Dorsey has personally funded with millions—Buzz aims to replace the fragmented "SaaS Tax" of tools like Slack and GitHub with a unified workspace where humans and AI agents have equal cryptographic standing.

In Dorsey's vision, agents aren't just background tools but verifiable participants with their own identities, ensuring that your data, your team's history, and your agents' reputations belong to you rather than a proprietary platform. This makes Buzz more than just a chat app; it is a high-stakes experiment to prove that the future of work can be open-source, auditable, and entirely independent of centralized vendor lock-in

What is Buzz, in simple words?

It has familiar things such as messages, channels, search, and direct messages. The difference is that an agent is treated like a real participant in the workspace. It has its own identity, its own settings, and a record of the work it does.

Block built Buzz as an open-source project on Nostr, a protocol that uses cryptographic keys for identity. In everyday terms, that means Buzz wants you, your team members, and your agents to have identities that are harder to fake and easier to verify.

For a first-time user, you only need to remember four ideas:

> Keep your private identity key private. Treat it like a password that cannot be reset. If someone gets it, they can act as you in Buzz.

Before you start setting up Buzz.xyz

Download the Buzz desktop app from buzz.xyz. You will also need an email address, because the hosted community setup runs through Builderlab.

If you already use Claude Code or Codex, keep that in mind for later. Buzz can detect those tools and connect them as agent harnesses. You do not need to set them up on the first run.

Understanding Relays (The Foundation)

The “Relay” is the part of Buzz that confuses most people. In simple terms, the relay is your team’s hard drive.

Traditional apps like Slack store your data on their own secret servers. Buzz is different: it stores your data on a “Relay” that follows an open protocol. This is why you own your data, but it also makes setup harder. You have two options:

Option 1: Use Block’s hosted relay — The easiest choice. Block runs and maintains the relay for you at no cost. Your community lives there, and you do not need to manage any infrastructure. This is what most people choose when starting out.

Option 2: Self-host your own relay — For teams that want complete control over their data. You run the relay on your own server or cloud provider (Railway, DigitalOcean, AWS, etc.). This costs $5-50 per month depending on team size, but you own everything.

For now, we will use Block’s hosted relay through Builderlab. If you want to self-host later, you can migrate or run both relays in parallel. The setup process is the same either way.

You can find it in settings to setup relay

Step-by-Step Setup Guide for Buzz.xyz

Step 1: Create your Buzz identity

Open Buzz. The first screen gives you two choices: create a new identity key or use one you already have.

Choose Create a new identity key if this is your first time. Choose Use an existing key only if you previously set up Buzz and saved your key.

Screenshot 1: Start by creating a new identity key.

Step 2: Save the private key before moving on

Buzz creates your identity key and stores it in your computer’s keychain. That is useful for everyday use, but it is not a backup.

Copy the key and save it in a secure password manager or another private place you trust. Do not paste it into a document, a chat app, or an email draft. Anyone who has this private key can use your identity.

Then click Next.

Screenshot 2: Save the key somewhere safe before you continue.

Step 3: Decide whether to connect Claude Code or Codex now

Buzz checks whether AI coding tools are already installed on your machine. In my setup, it found Claude Code and Codex, but the ACP adapters were still missing.

If you already know how you want to use those tools, set them up here. If you only want to get into Buzz and look around, click Skip for now. You can come back later.

This is a useful design choice. Your workspace does not depend on one AI model. You can bring your own provider and change it later.

Screenshot 3: You can connect agent tools now or skip this step.

Step 4: Choose how you want to enter Buzz

Next, Buzz asks where you want to work. You can join an existing community with an invite, reconnect to a community you already own, or create a new one.

For a new team space, choose Create a community.

Screenshot 4: Create a community if you are starting a new workspace.

Step 5: Open Builderlab to create the community

Buzz now explains that it will open Builderlab in your browser. Builderlab is the service that creates your hosted relay and manages your community.

Click Sign in to continue. The browser will open automatically.

Screenshot 5: Buzz sends you to Builderlab for the hosted community setup.

Step 6: Sign in and verify your email

In Builderlab, enter your email address and click Continue. If you do not have an account, use the sign-up link on the same page.

Screenshot 6: Sign in to Builderlab with your email address.

Builderlab sends a verification link to your email. Open that link, return to this page, and click I’ve verified my email.

If the email does not appear, check your spam folder first. Use the resend option only after a few minutes.

Screenshot 7: Verify your email before you can create a community.

Step 7: Connect your Buzz identity to Builderlab

Now Builderlab needs to know which Buzz identity owns the community. Click Connect your Buzz identity.

Screenshot 8: Connect the identity you created in the Buzz desktop app.

Builderlab gives you a six-digit code. Click Copy code and open Buzz. This sends you back to the desktop app, where Buzz completes the connection.

Screenshot 9: Copy the six-digit pairing code and return to Buzz.

When it works, Builderlab confirms that your Buzz identity is connected. You will see your Nostr ID and the option to create a community.

Screenshot 10: Your identity is now linked to Builderlab.

Step 8: Name and create your community

Click Create Community. Choose a short, readable name. That name becomes part of your community address.

In this example, I used thetoolnerd, which created the address thetoolnerd.communities.buzz.xyz.

Screenshot 11: Pick the name that will become part of your community address.

After you click Create, the new community appears in the Builderlab dashboard. You can copy its address or click Open in Buzz.

Screenshot 12: The community is ready. Open it in the Buzz app.

Step 9: Let Buzz join the community

Click Open in Buzz. The desktop app shows a short connection screen while it joins the community securely.

Wait for this to finish. You do not need to enter the address manually unless the automatic hand-off fails.

Screenshot 13: Buzz connects the desktop app to your new community.

Step 10: Build your profile

Buzz asks for a username and an optional avatar. This is how your name appears in messages, reactions, and agent handoffs.

Use a name your team will recognise. You can always refine your profile later.

Screenshot 14: Add the name and avatar other people and agents will see.

Step 11: Meet the starter team

Buzz creates three starter agents: Fizz, Honey, and Bumble. The app uses them to help you understand the workspace and test basic agent collaboration.

Click Take me to Buzz.

Screenshot 15: The starter agents are ready to help you learn the workspace.

Step 12: Send your first message in the workspace

You are now inside Buzz. The left sidebar contains Inbox, Agents, and your channels. The private #Welcome channel is a good place to start.

Fizz posts the first message. You can reply directly, mention an agent with @, create a new channel, or create another agent. Start with a small task, such as asking the agents to help plan a blog outline or research a tool.

Screenshot 16: Your first private channel, with shortcuts to create a channel or agent.

Set up an agent after the workspace is ready

You do not need to understand every agent setting on day one. Start by opening Agents in the sidebar and selecting one of the starter agents.

The edit screen lets you choose who can talk to the agent, which runtime it uses, and which model provider powers it. The provider menu in my setup included Anthropic, OpenAI, OpenAI-compatible services, Buzz shared compute, and Databricks options.

Screenshot 17: Pick the LLM provider that will power an agent.

The Agents page gives you a simple control centre. You can see your agent cards, add a new agent, check which model is selected, and stop running agents if needed.

Screenshot 18: Manage starter agents or add a new one from the Agents page.

Each agent has its own profile. This screen shows the agent’s public key, runtime status, connected channels, memory count, and who manages it. That is one of the clearest examples of what makes Buzz different from a normal chatbot. The agent has an identity inside the workspace.

Screenshot 19: Every agent has a visible profile and a separate identity.

Advanced Features: Experiments, Shared Compute, and More

Once you are comfortable with the basics, Buzz has several powerful features worth exploring. These are optional but can dramatically change how you work.

Experiments Panel: Unlock Advanced Features

Buzz hides some features behind an Experiments panel until you are ready for them. To access these features, go to Settings → Experiments and toggle them on.

The main experimental features are:

Workflows — Automate recurring tasks with YAML-defined automations and approval gates. For example, you can set up a daily workflow that pulls data from an API into a channel, or runs a test suite on code changes.

Projects — Browse and collaborate on Git repositories directly inside Buzz. Code review, pull requests, and CI status all appear in the same event log as the conversation about the code.

Pulse — An activity feed that shows notes, social posts, and agent activity in one place. Useful for tracking what your team and agents are doing.

Forum Channels — Traditional threaded forum-style channels for long-form discussions, separate from your main chat channels.

Agent-managed profiles — Let agents manage their own relay name and avatar instead of copying from your desktop settings.

These features are functional but still being refined. Start with one or two and add more as you get comfortable.

Shared Compute: Reduce Costs for Your Team

One of Buzz’s most distinctive features is shared compute. This lets you share your machine’s computing power with your team, so everyone can run agents on a single powerful machine instead of paying for expensive API plans.

Here is how it works: Go to Settings → Compute and toggle on Share this machine with your relay. Buzz will suggest local models optimized for your hardware (for example, Gamma-4 for an Apple M4 with 12GB RAM). Download a model and enable sharing.

Now, any team member on your relay can run agents on your machine. This is powerful for small teams. A college student with limited budget can join a team, and everyone pools resources into one Mac Studio or Mac Mini. Everyone gets access to a powerful model without paying $200 per month for API access.

Local models keep improving. This feature makes it practical for teams to use open-source models instead of proprietary APIs.

Model Swapping Without Losing Context

One of Buzz’s strongest features is that you can switch an agent’s underlying model without losing any context. If you are chatting with an agent powered by Claude, and you switch it to Codex or a local model, all the chat history, project context, and agent skills travel with it.

This matters because AI moves fast. New models ship every week. Instead of being stuck with one model, Buzz lets you experiment and adapt without starting over.

Real-World Workflows

Here are some practical examples of what teams are doing with Buzz:

Deploy an app in a conversation — Ask an agent to build a full-stack app using Wasp framework and deploy it to Railway. The agent writes the code, pushes to a repo, deploys to production, and sends screenshots back in the chat. You review the live app and ask for changes.

Analyze data with historical context — Set up a daily workflow that pulls tweet stats into a channel. Then ask an agent to find the common thread across your top tweets. Because the agent has the historical data it has been posting, it can analyze trends and give actionable insights.

Work in parallel — Ask agents to create three different versions of a landing page based on ideas discussed in chat. They work in separate feature branches without overwriting each other’s work.

Voice huddles with context — Start a live voice call with an agent. You speak to them, they reply with voice, and they retain all the context from your text chat.

The Chief Agent Officer Pattern

As your roster of agents grows, instead of managing each one individually, create a meta-agent called a “Chief Agent Officer.” Give it a task, and let it delegate to specialized agents (copywriter, coder, reviewer, etc.). This reduces decision fatigue about which agent to use.

“Where are my files?” - Understanding File Access

One common point of confusion is how to actually see or touch the files your agents are working on.

In Buzz, agents work in “Work Trees.” When you ask an agent to write code or create a file, it doesn’t just overwrite your local documents. It creates a separate branch or “version” of the project. To see these files:

1. Enable the Projects experiment in Settings.

2. Use the Git repository browser inside Buzz to see the different branches.

3. You can “check out” or download the files once you are happy with the agent’s work.

Locally, agent-created files are stored in: ~/Users/{your_user_name}/.buzz

This keeps your main files safe, but it adds an extra step that can feel clunky if you just want a quick file export.

The three parts that confused me at first

The setup is easy once you understand the order, but three terms can slow down a first-time user.

The other possible sticking point is the agent harness screen. Ignore it on your first pass if you are not already using Claude Code or Codex. Build the community first. Add the harness later when you have a clear reason to use it.

Honest limitations and early-stage reality

Buzz is new and still evolving. Here are the things you should know:

Workflows and recurring tasks are still rough. The feature exists, but reliability is not perfect yet. Test them with non-critical tasks first.

Speed lags behind direct CLI tools like Claude Code or Codex. Everything routes through your relay and back, which adds latency.

For complex software engineering, you might prefer direct CLI tools. For team collaboration and agent coordination, Buzz is faster.

Voice huddles exist but are not fully tested in production. I wasn’t able to test the feature

Buzz is best for solopreneurs and small teams iterating on small products. For complex software engineering or large-scale operations, you might need additional tools.

If you are comparing approaches to agent work, read my Hermes Agent vs OpenClaw guide and browse the TheToolNerd automation directory. You can also read my framework for selecting the right AI agentic framework.

Sources

• TechCrunch, “Jack Dorsey is taking on Slack with Buzz, a group chat platform for teams...”

• PYMNTS.com, “Dorsey’s Block Turns AI Agents Into Real Employees”

• Daily.dev, “Jack Dorsey launches Buzz, an open-source workspace that...”

• Block, “Introducing Buzz: where humans and agents work together”

• Block Engineering, “Buzz!”

• Buzz on GitHub

• The Startup Ideas Podcast, “Buzz: Slack with agents inside”

• Railway, “Deploy & Host Buzz Relay”

• TechCrunch, “Jack Dorsey is taking on Slack with Buzz, a group chat platform for teams...”

• PYMNTS.com, “Dorsey’s Block Turns AI Agents Into Real Employees”

• Daily.dev, “Jack Dorsey launches Buzz, an open-source workspace that...”

• CryptoBriefing, “Block launches Buzz, a Nostr-based rival to Slack and GitHub”

Screenshots in this guide were captured during the setup of the TheToolNerd Buzz community on July 28, 2026. Product screens and available options may change as Buzz evolves.

If you tried to build an AI agent a year ago, you know the slog. You had to learn LangChain, then LangGraph, then how Pydantic fit into all of it. Wiring up MCP servers was a project of its own. Registering tools, loading skills, managing state — each one a task in itself before your agent did anything useful.

In just the last eight weeks, that entire stack collapsed into one instruction.

Make a folder.

Drop in an instructions.md for its personality. A tools/ folder for what it can do. A skills/ folder for what it knows. Run one command — and the folder is the agent. No graph to hand-wire. No orchestration layer. Just files you can read, edit, and version.

Three frameworks landed this idea almost simultaneously: Flue (from the Astro team), Vercel Eve, and Mastra. I think file-based AI agents are the biggest shift in how we build agents since MCP.

Check out my previous articles

Subscribe now

What Are File-Based AI Agents?

A file-based AI agent is exactly what it sounds like: an agent defined by a folder of files instead of hand-wired code. You create a directory, drop in an instructions.md for its personality and system prompt, a tools/ folder for what it can do, and a skills/ folder for what it knows. Run one command and the folder is the agent.

There’s no graph to construct, no orchestration layer to reason about — just files you can open in any text editor and version like any other project.

The point is that everything an agent needs is now plain, portable material. Its identity, its knowledge, its capabilities all live as markdown and TypeScript on disk. You can read it, diff it, fork it, and move it between frameworks.

Three frameworks shipped this pattern in eight weeks.

The Astro team launched Flue (”The Open Agent Framework”), with 1.0 Beta on June 16, 2026.

Vercel announced Eve (”Next.js for agents”) at its Ship conference on June 17, 2026.

Mastra, an established ~24k-star framework, shipped File-Based Agents on July 3, 2026. Three independent teams, the same answer — that’s convergence.

Flue Framework: The Astro Team’s Agent Harness

Github Repo: https://github.com/withastro/flue

What it is. Flue is a TypeScript framework for durable AI agents and workflows, built around what it calls an “agent harness” — “like Claude Code, but 100% headless and programmable.” It comes from the Astro team and was announced by Astro co-founder Fred K. Schott. It went public around May 1, 2026, and hit 1.0 Beta on June 16, 2026. As of July 22 it’s Apache-2.0, ~4.4k stars, and openly flagged Experimental — APIs may change.

How the folder looks. Flue is more code-first than the others — TypeScript agents, markdown skills:

my-agent/
  flue.config.ts                     # the only thing `flue init` scaffolds
  agents/hello-world.ts              # defineAgent(() => ({ model, tools, skills, ... }))
  .flue/workflows/<name>.ts          # run({ init, payload }) + optional Hono route
  .agents/skills/<name>/SKILL.md     # markdown skills (or import with { type: 'skill' })
  AGENTS.md                          # context, discovered from cwd
  channels/                          # @flue/slack, etc.

How it works. Flue records everything your agent does, so if a run gets interrupted — crash, restart, whatever — it picks up right where it left off. And the same agent folder runs anywhere: Node.js, Cloudflare, GitHub Actions, or GitLab CI/CD.

Need external tools? MCP servers plug in with a single function call.

Install it. One caveat: flue init is deliberately minimal. It scaffolds only a flue.config.ts; you write the agent file yourself. It’s not a full project generator like the other two:

npm install @flue/runtime && npm install -D @flue/cli
echo 'ANTHROPIC_API_KEY="..."' > .env
npx flue init --target node        # or --target cloudflare
# create agents/hello-world.ts yourself, then:
npx flue run hello-world --input '{"message":"Tell me a joke."}'

Requires Node >=22.19.0.

The repo (github.com/withastro/flue) ships runnable examples — examples/node-websocket and examples/cloudflare-websocket are the fastest way to see a live agent.

The honest knock, from Flue’s own Hacker News launch thread: no tests in packages/ yet, and it’s early (Experimental for a reason). Worth knowing before you build anything load-bearing on it.

Vercel Eve: Next.js for Agents

Github Repo: github.com/vercel/eve

What it is. Eve is Vercel’s open-source agent framework, announced June 17, 2026 at Vercel’s Ship conference in London as part of its “Agent Stack.” It’s Apache-2.0 (npm eve, github.com/vercel/eve), and as of July 22 it’s at ~3.9k stars and version 0.27.0 (a public beta).

Vercel CTO Malte Ubl’s framing is the cleanest one-liner of the bunch: it’s “Next.js for agents.” The way Next turns folders into routes, Eve turns folders into agents — discovered at build time.

How the folder looks. This is the purest expression of “agent = directory”:

agent/
  agent.ts          # optional: model + runtime config (defineAgent)
  instructions.md   # required: the always-on system prompt
  tools/*.ts        # defineTool + Zod schema; filename = tool name
  skills/*.md       # markdown w/ frontmatter, loaded on demand
  subagents/<name>/ # child agents, same shape one level down
  channels/*.ts     # slack.ts, discord.ts...; HTTP on by default
  schedules/*.ts    # defineSchedule({ cron, run })
  connections/*.ts  # defineMcpClientConnection (MCP or OpenAPI)

A minimal agent is two files: instructions.md plus an optional agent.ts.

How it works. Your agent survives crashes and redeploys — Eve saves its progress automatically. Each agent gets its own sandbox to run code safely, and if you want a human to approve an action before it happens, that’s one flag on a tool. Out of the box it connects to Slack, GitHub, Snowflake, Salesforce, Notion, and Linear. Vercel says it runs 100+ agents internally, including one resolving 92% of support tickets (their numbers, not independently confirmed).

Install it. Unlike Flue, Eve gives you a full scaffold — directory, dependencies, git init, and a terminal UI, all in one command:

npx eve@latest init my-agent    # scaffolds dir, installs deps, git init, launches TUI
npm run dev                     # or: npx eve@latest init .  for an existing project

Deploy with vercel deploy. There are polished official templates from vercel-labs worth cloning directly:

# Slack bot: one tool + one skill, Vercel Connect creds
git clone https://github.com/vercel-labs/eve-slack-agent-template
# Durable personal agent: web chat, Slack, Linear, long-term memory
git clone https://github.com/vercel-labs/personal-agent-template

There’s also eve-chat-template and eve-content-agent-template. The fair criticism: this is Vercel-native. The code is Apache-2.0, but the durable runtime, sandbox, and gateway are most seamless on Vercel — the launch post says other platforms are “on the way.” I dug into exactly this playbook in Vercel’s Open-Source Empire: give away the framework, monetize the hosting underneath.

Check out more about Vercel’s Open-Source Empire in this article.

Subscribe now

Mastra File-Based Agents: A 24k-Star Framework Converts

Github Repo: https://github.com/mastra-ai/mastra

What it is. This is the one that convinced me the shift is real. Mastra is a YC-backed, open-source TypeScript agent framework with roughly 24k GitHub stars — a mature, code-first project.

On July 3, 2026, in @mastra/core@1.48.0, it shipped File-Based Agents (announced by Paul Scanlon). When a framework that big adopts the folder convention on top of its existing code API, that’s not a startup chasing a trend — that’s convergence.

How the folder looks. Each agent is a directory under src/mastra/agents/:

src/mastra/agents/<name>/
  config.ts          # model config
  instructions.md    # the prompt
  memory.ts
  workspace/         # seed files
  tools/*.ts
  skills/            # plain .md, .ts, OR SKILL.md packages with references/
  subagents/         # recursive, up to 3 levels deep

How it works. The killer detail is the skills/ folder: it accepts Anthropic’s SKILL.md format directly — write a skill once, and it works in Claude and in Mastra. File-based agents also work side by side with Mastra’s existing code-defined agents, so teams can switch over gradually instead of rewriting everything. Run mastra dev and your agent folders are picked up automatically.

Install it. Mastra’s CLI is a proper project generator — it scaffolds a working example agent for you:

npm create mastra@latest            # interactive; scaffolds src/mastra with an example agent
npm create mastra@latest my-app -- --default
npx mastra dev                      # file-based agents are discovered here

One licensing nuance to flag: the Mastra core is Apache-2.0, but the ee/ directory sits under a separate Mastra Enterprise License. The file-based agent feature itself is in the Apache-2.0 core, still marked beta and only a few weeks old. Templates live at mastra.ai/docs/getting-started/templates — start there rather than digging through the monorepo.

Flue vs Eve vs Mastra: Quick Comparison

All Three Are Open Source (Apache-2.0)

Here’s what makes me optimistic about this wave: all three are Apache-2.0. Flue, Eve, and Mastra’s core are all on GitHub under a permissive license — read every line, fork it, self-host.

Mastra draws the one line worth knowing (its ee/ directory is under a separate enterprise license), but the file-based agent feature lives in the open core. And the conventions are open too: AGENTS.md and MCP now live at the Linux Foundation’s Agentic AI Foundation, and SKILL.md is Anthropic’s open spec. That’s why Mastra can accept a Claude skill unchanged, and why an AGENTS.md you wrote for OpenClaw or Codex or any platform isn’t wasted when you move to Flue.

> Your agent folder is portable in a way your agent graph never was.

Final Verdict: Who Should Use What

• Non-coders and indie builders — this is your entry point. If you can write a clear markdown file, you can define an agent. It’s the same promise Claude Skills made, now extended to full deployable agents.

• TypeScript and web developers — Eve if you live on Vercel and want the most polished DX, Flue if you want to deploy anywhere, Mastra if you want a mature ecosystem and drop-in Claude-skill compatibility.

• Python teams on LangGraph or PydanticAI — you’re not stranded. Pydantic AI V2 shows the ideas flowing your way. Start moving your prompts and skills into files now; that’s becoming the portable layer regardless of which engine runs underneath.

For two years the question was “which agent framework should I learn?” The answer arriving now is simpler and a lot more durable:

> Learn to write good files. The frameworks will meet you there.

Vercel is shipping production-grade AI infrastructure at a pace most companies reserve for their core products—and doing it in public. Across two GitHubs, 558 repositories the company is building an entire stack for AI agents while keeping the frameworks millions of developers rely on stable and boring.

This isn’t a story about counting repos. It’s about how Vercel turns free open-source tools into demand for its paid infrastructure, and how splitting its work across two organizations lets it move fast on agents without breaking Next.js.

If you would like to check out my previous articles, please check out here.

Subscribe now

The Vercel Flywheel: Open-Source as Distribution

Consider Next.js. It’s free. It’s open-source. Millions of developers use it without ever paying Vercel a dollar. But those developers are the target. They use Next.js to build their applications. When it comes time to deploy, Vercel’s platform is the natural choice—it’s optimized for Next.js, it’s faster, and it just works. That’s when Vercel makes money.

The same pattern repeats across their entire ecosystem. Open-source projects create awareness and adoption. Hosted services monetize the infrastructure. Premium features and enterprise offerings capture additional value.

Six Layers of Developer Infrastructure

Vercel’s open-source portfolio organizes into six strategic layers, each serving a different part of the developer experience:

1. AI & Model Access (11 Projects)

The AI SDK is the foundation. With 25,558 GitHub stars and 15.8 million weekly npm downloads, it’s the most downloaded package in Vercel’s entire ecosystem. And it’s not a Vercel-only tool—it works with any LLM provider (OpenAI, Anthropic, Cohere, local models) and any framework.

The supporting projects in this layer tell the story. Streamdown renders streaming Markdown for AI output. AI Elements provides pre-built UI components for AI applications. Chatbot is a reference implementation. Together, they form a complete toolkit for building AI applications.

Key projects:

• AI SDK — 25,558 stars, 15.8M weekly downloads

• Streamdown — 5,397 stars, 24.3% npm growth

• AI Elements — 2,219 stars, -17.7% npm growth

• Eve — 3,511 stars, 206.8% npm growth (launched June 2026)

2. Agents, Channels & Skills (16 Projects)

This is where Vercel’s emerging strategy becomes visible. Eve is the opinionated production agent framework. Chat SDK unifies communication channels (Slack, Teams, Discord, Telegram). The Skills CLI and agent-skills repository form an ecosystem for reusable agent capabilities.

Agent Browser, launched in January 2026, already has 38,453 stars. Skills has seen 488% npm growth in the last four weeks.

Key projects:

• Agent Browser — 38,453 stars, 7.9% npm growth

• Skills — 26,145 stars, 488.2% npm growth

• Eve — 3,511 stars, 206.8% npm growth

• Chat SDK — 2,195 stars, 57.9% npm growth

• Agent Skills — 29,067 stars

3. Execution & Compute (7 Projects)

Vercel Workflow SDK enables long-running TypeScript jobs and agent loops. Vercel Sandbox provides ephemeral isolated compute. These are the execution primitives that power Vercel’s hosted Workflow and Sandbox services.

The open-source SDKs let developers build and test locally. The hosted services handle the infrastructure, scaling, and reliability. Vercel charges per execution minute and per compute resource.

Key projects:

• Workflow SDK — 2,205 stars, 515,627 weekly downloads

• Sandbox SDK — 2,814,701 weekly downloads, 23% npm growth

• Tersa — 1,020 stars (AI workflow canvas)

• Emulate — 1,515 stars (local API emulation)

4. Platform & Infrastructure (11 Projects)

Vercel SDK is a type-safe REST API client for the entire Vercel platform—deployments, domains, DNS, registrar, remote cache, observability. It’s not just a domain SDK; it’s the distribution surface for all platform features.

Storage clients (Blob, Edge Config), Analytics client, Flags SDK, Edge Runtime—these are all open-source. Vercel monetizes through subscriptions (hosting, domains, storage), usage-based pricing (storage, bandwidth, cache hits), and transactions (registrar purchases).

Key projects:

• Vercel CLI — 15,917 stars, 2.7M weekly downloads

• Vercel SDK — 275,812 weekly downloads, 6.9% npm growth

• Flags SDK — 730,711 weekly downloads

• Analytics Client — 3.5M weekly downloads

• Edge Runtime — 2.4M weekly downloads

5. Frameworks & Developer Tooling (12 Projects)

Next.js is the flagship. One hundred forty-one thousand stars. Forty-two million weekly downloads. Turborepo is the build system for monorepos. SWR is the data-fetching standard. Satori generates dynamic images. Styled-JSX scopes CSS. Together, they form the developer experience layer that drives adoption of Vercel hosting.

Vercel monetizes through platform features (remote cache, advanced analytics, edge functions) and hosting. The open-source projects are so good that developers use them regardless of where they deploy. But Vercel’s platform is optimized for them, so most developers end up on Vercel anyway.

Key projects:

• Next.js — 141,107 stars, 42.1M weekly downloads

• Turborepo — 30,716 stars, 17.0M weekly downloads

• SWR — 32,431 stars, 12.6M weekly downloads

• Satori — 13,647 stars, 1.8M weekly downloads

• Styled-JSX — 32.2M weekly downloads

6. Templates & Learning (5 Projects)

Next.js Commerce is a reference implementation for e-commerce. Platforms Starter Kit is a template for multi-tenant SaaS. These templates drive adoption of Vercel hosting and are monetized through the Vercel Marketplace and template gallery.

Key projects:

• Next.js Commerce — 10,000+ stars

• Platforms Starter Kit — 8,000+ stars

• Next Learn — Learning resources

How Vercel makes money

Every layer follows the same four-step arc: adopt the free SDK locally, build something real, run it in production on Vercel, and Vercel monetizes the compute, deployments, token routing, and storage underneath.

It works because the open-source projects are genuinely useful on their own. You can use the AI SDK without Vercel, run Eve without deploying to Vercel, ship Chat SDK without Vercel Connect. But once you’ve built something real, Vercel’s infrastructure is the path of least resistance to running it.

The Vercel Agent Stack: Where New Revenue Grows

The agent stack is where Vercel’s emerging strategy becomes most visible. It’s also where the momentum is highest.

Eve is the runtime. Chat SDK provides channel adapters. Workflow handles durable orchestration. Sandbox provides isolated execution. AI SDK feeds models and tools. Skills provide reusable capabilities. Together, they form a complete system for building production agents.

Vercel is providing the open-source tools to build them locally, then offering the hosted infrastructure to run them at scale.

If you are developer - which Vercel Projects Should You Use?

Vercel’s real trick is that none of its open-source tools need Vercel to be useful. You can run Next.js, the AI SDK, or Eve anywhere. But once you’ve built something real, Vercel’s infrastructure is just the easiest place to run it — and that’s where the money is.

The agent stack is the part to watch: it’s the newest bet, it’s growing the fastest, and it’ll show whether the same playbook that made Next.js a default can work all over again.

I’ve been using Claude Code daily for months. And honestly, the things that have made me more productive are the discovery of these commands over time - not all at once, but gradually, as I kept running into situations where I needed more control.

There are so many commands. As you use the product on a daily basis, you start seeing which ones are actually useful for your workflow and which ones you’ll never touch. In this article, I’ve tried to summarize the ones I regularly use, plus a few that the community has flagged as genuinely powerful. If you’re just getting started with Claude Code, this will save you weeks of discovery.

What Are Claude Code Commands?

Claude Code commands are slash-prefixed instructions and CLI arguments that control how Claude operates at a session and workflow level. They go beyond prompting. You’re not asking Claude to do something - you’re configuring how it thinks, branches, loops, and executes.

The difference matters. A prompt tells Claude what to do. A command tells Claude how to operate.

Check out my previous articles on the best Claude Skills, Best Agent Harnesses:

Subscribe now

Session Management: Control Your Context Before It Controls You

Context pollution is the silent killer of long Claude sessions. You start sharp, then twenty turns in, Claude is carrying irrelevant history into every response. These commands exist to prevent that.

/branch — Split Your Session, Keep Your Sanity

/branch creates an independent copy of your current session at that exact point. Both branches share the same history up to that moment, then diverge completely.

I use this whenever I have two competing approaches to a problem and I don’t want to pick one blind. Branch, test both, keep the one that works.

/branch "try-redis-cache-approach"

Use it when you’re exploring alternatives, testing different fixes, or want to experiment without touching your main session.

/fork — Spin Off a Subagent

/fork spawns a background agent that inherits the full conversation context. The key difference from /branch: you’re not creating a parallel version of yourself - you’re delegating a task to a subagent that runs independently while you continue in the main session.

/fork "run security audit on the auth module"

/rewind — Undo Without Starting Over

/rewind is the undo button Claude should have had from day one. It lets you restore your session - code, conversation, or both - to any previous point. The screenshots above show the two views: the history picker showing each prompt with its file diff, and the restore options (restore code and conversation, restore conversation only, restore code only, or summarize from that point).

This is not just cosmetic. If Claude made file changes you want to roll back, /rewind handles that too - you’ll see the exact diff before confirming.

/rewind

Use it when Claude goes off-track, when a prompt led somewhere unproductive, or when you want to try a different direction from a known-good state.

/resume — Pick Up Any Session by Name

Working across multiple projects means multiple sessions. /resume lets you jump back into any named session with full context intact.

/resume "auth-module-bugfix"

/rename — Keep Your Sessions Findable

As sessions multiply, names matter. /rename lets you update a session name as the work evolves.

/rename "session-1" "payment-api-refactor-v2"

Planning and Execution: From Idea to Implementation

/plan — Think Before You Build

/plan puts Claude into a collaborative planning mode. Before any code is written, you and Claude work through the problem together - defining scope, exploring approaches, identifying risks. This is where I start every non-trivial task.

The right workflow is: use /plan to align on strategy first, then move to execution. Once the plan is solid, that’s when you bring in /effort ultracode.

/plan
Refactor the billing module to support multi-currency pricing

/effort ultracode — Dynamic Workflow Orchestration

This one needs a proper explanation because there’s a lot of confusion about what “ultracode” actually is.

ultracode is not just a higher effort level. It’s two things depending on how you use it.

As a keyword in a prompt, typing ultracode in your message triggers Claude to write a dynamic workflow for that specific task - a JavaScript orchestration script that a background runtime executes, coordinating up to 16 concurrent subagents. Intermediate results live in script variables, not in Claude’s context window, which is what lets it scale past what a single conversation can coordinate.

As a session setting (/effort ultracode), it combines xhigh reasoning effort with automatic workflow orchestration for every substantive task in the session. Claude plans a workflow for each task without waiting for you to ask. One request can turn into several workflows in sequence - one to understand the code, one to make the change, one to verify it.

This is what makes it genuinely autonomous. You’re not prompting Claude through steps. You’re giving it a task and letting the orchestration layer figure out how many agents to spin up, how to partition the work, and how to verify the result.

/effort ultracode

Or trigger a single task as a workflow:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

A practical note: this is expensive by design. The docs recommend dropping back to /effort high for routine work and using ultracode only when the task genuinely needs multi-agent orchestration - codebase-wide audits, large migrations, cross-checked research.

Autonomous Operation: Let Claude Work While You Don’t

/goal — Define Done, Then Step Away

/goal sets a verifiable end condition. Claude works toward it continuously - spawning subagents, running tests, iterating - until a separate evaluator model confirms the condition is met.

No more typing “keep going” every three files. No more babysitting a migration.

The key is writing the condition like a contract. “All tests in test/auth pass and git status is clean” works. “Make it better” does not.

/goal all 17 service files migrated to the new auth API, all tests passing, no regressions

A developer on Reddit ran a 9-hour autonomous /goal session that produced 45 commits and ingested 4.16 million rows of data across 5 successive passes with 41 subagent invocations. The session chained 4 self-paced goal commands. That’s the ceiling of what this command can do when you write the condition precisely.

Use it for large refactors, backlog clearing, migrations - any task where the finish line is clear and verifiable.

/loop — Recurring Tasks Inside Your Session

/loop runs a prompt repeatedly on an interval you define. You can set a fixed cadence or let Claude choose dynamically based on what it observes - shorter waits when a build is active, longer waits when nothing is pending. Sessions can hold up to 50 scheduled tasks. Tasks expire after 7 days.

/loop 15m check CI status and flag any failures

Use it for CI polling, periodic cleanup, or any monitoring task you want running in the background while you work.

/schedule (Routines) — Cloud Automation That Outlives Your Session

/loop stops when your session ends. /schedule doesn’t.

Routines run on Anthropic-managed infrastructure - they keep firing whether your laptop is open or not. You can trigger them on a cron schedule, via an API endpoint, or based on GitHub events like a PR being opened.

/schedule daily PR review at 9am
/schedule list
/schedule run

Use it for daily backlog grooming, automated code reviews on every PR, deploy verification scripts, or anything you’d otherwise set up in a cron job.

Code Quality: Review Without the Bottleneck

/code-review and /review — Catch Issues Before They Ship

Claude offers two distinct review modes depending on where you are in the workflow.

/code-review is for local, in-session reviews. Run it against your current diff and Claude flags issues by correctness, reusability, simplification, and efficiency. Fast feedback before you commit.

/review (as part of the Code Review feature) is for pull requests. It runs multiple agents in parallel, analyzes changes across the codebase, and posts inline comments sorted by severity. This integrates directly into your CI/CD pipeline.

/code-review

Use /code-review before pushing. Use /review as part of your PR workflow when you want automated, multi-agent analysis before human review.

Extensibility: Build Claude Into Your Workflow

Hooks — Automate Responses to Events

Hooks let you inject logic at specific points in Claude’s workflow. You can use the built-in hooks that come with Claude Code, or build your own through hook development. Whether it’s running a linter before code is committed, sending notifications, or enforcing custom permissions - hooks fire automatically at the right moment without you having to prompt for it.

/hooks

Use hooks when you want Claude’s behavior to respond automatically to events rather than waiting for your input.

Skill Creator — Teach Claude Your Workflows

Skills are reusable playbooks defined in a SKILL.md file. You write the instructions once, and Claude loads them whenever that skill is relevant. This is how you encode domain-specific knowledge - your team’s review checklist, your deployment process, your debugging methodology - so Claude applies it consistently across sessions.

I’ve written a full breakdown of the 10 best Claude skills worth installing at TheToolNerd.com. If you’re serious about extending Claude, that’s the place to start.

mkdir ~/.claude/skills/my-workflow
# Create SKILL.md with your instructions

Plugins — Package and Share Extensions

Plugins bundle commands, agents, skills, hooks, and MCP servers into a distributable package. The Plugins Marketplace (shown above) already has official Anthropic plugins, community plugins like caveman and claude-code-warp, and the claude-plugins-official registry with 255 available plugins.

Use plugins when you’ve built something worth reusing across projects or sharing with a team.

Agent Management: See What Your AI Workforce Is Doing

claude agents — Your Agent Control Panel

The claude agents panel shows every active session in one view. You can see which agents are working, which need your input, and which have completed. The panel above shows a real session: 3 agents awaiting input, 1 working, 2 completed - with task names, last activity, and PR counts visible at a glance.

From here you can attach to any session, dispatch new tasks, or review completed work without losing context in your main session.

claude agents

Use it any time you’re running more than one agent in parallel. Without this view, you’re flying blind.

A Few More Worth Knowing

/compact manages your context window during long sessions. When a conversation gets unwieldy, /compact intelligently summarizes the history so Claude stays sharp without losing the thread.

The WebSearch and WebFetch tools let Claude pull live information from the internet mid-workflow - useful for research tasks, documentation lookups, or validating external data.

AskUserQuestion lets Claude pause and ask you a clarifying question with multiple-choice options before proceeding. Underrated for complex tasks where ambiguity early on causes wasted work later.

The Bottom Line

The developers getting the most out of Claude Code aren’t using better prompts. They’re using the right commands for the right situations.

Start with /plan before any complex task. Use /branch when you have competing approaches. Set a /goal when the finish line is clear and you want Claude to drive itself there.

Build a skill for any workflow you repeat more than twice. And when a task genuinely needs multi-agent orchestration, ultracode is the switch that moves execution out of the conversation and into background agents.

The commands are the operating layer. Once you know them, you stop prompting and start orchestrating.

I used to spend a lot of time confused about where I fit.

I’m not a traditional developer. I don’t write production code all day. But I build products. I can conceptualize an idea and materialize it into a working prototype faster than most. But here’s the reality: most of the ideas I build never see the light of day. They don’t ship.

For a long time, the question I dreaded most in organizational planning was, “Where do you fall in the org chart?”

If you’re a builder who spans multiple disciplines, you’ve probably felt this tension. The way tech organizations were built over the last two decades—rigid silos of Product, Design, and Engineering—is fundamentally incompatible with how software is built today.

Recently, Boris Cherny (the creator of Claude Code) posted an observation that perfectly encapsulated my dilemma. He foresees that future roles might be categorised into five distinct “archetypes” [1].

Your job title is dead.

If you would like to read my previous articles, check them out here:

Subscribe now

The 5 Archetypes Replacing Software Engineering and Product Roles

Boris Cherny is the creator of Claude Code. He recently posted an observation about how his team at Anthropic operates — that engineering, product, design, and data science are melting into a new kind of role. When he looks at the Claude Code team, he doesn’t see front-end devs or UX researchers. He sees five archetypes [1].

1. The Prototyper: Comes up with brand new ideas. Churns out dozens of concepts, most of which don’t ship.

2. The Builder: Quickly turns a prototype or idea into a production-grade product or infrastructure.

3. The Sweeper: Cleans up the UI, simplifies the codebase, unships dead features, and optimizes performance.

4. The Grower: Takes a product that has found its footing and iterates relentlessly to improve Product-Market Fit.

5. The Maintainer: Owns a mature system, ensuring it remains secure, reliable, fast, and efficient as it scales.

Reading that list was a relief. My “problem” — that I prototype fast but most of my ideas don’t ship — isn’t a bug. It’s the exact, necessary definition of the Prototyper archetype.

The critical nuance Cherny points out is that these roles are entirely decoupled from job functions. Across Anthropic, some designers are Prototypers. Some are Builders. Some engineers are Sweepers; others are Growers. Many people span two or even three of these roles simultaneously. The labels on our LinkedIn profiles are lagging indicators of a reality that has already shifted.

How AI Coding Assistants Inverted the Product Development Process

Now here is where it gets interesting. Cherny’s framework explains who the roles are. AJ Ambrosino, the Engineering lead for OpenAI’s Codex, explains why those roles exist at all — and why the old ones don’t.

In a recent conversation with Lenny Rachitsky, Ambrosino laid this out plainly. The old product process was built on a single, immovable assumption: building things is expensive. Because coding took months, teams had to de-risk everything upfront with PRDs, user research, and endless meetings asking, “Should we build this?” [2]

That assumption is dead. Implementation is now cheap.

The hard work has shifted. It’s no longer about planning; it’s about synthesis. The new question is not whether to build it, but:

When the cost of generating code drops to near zero, the value of a “pure coder” drops with it. The value shifts entirely to judgment. As I wrote in The Token Test, the elite engineers of 2026 aren’t the ones who write the most code — they’re the ones who architect systems so clearly that AI executes them perfectly on the first pass.

Your Job Title Is Irrelevant — Your Time Allocation Defines Your Role

So if you aren’t defined by your title, what defines you?

Ambrosino offers a brutal, clarifying diagnostic: your role is defined by the average of what you spend your time on.

If you average out everything you do in a forty-hour week, where do the dots land? If you spend sixty percent of your time iterating on features to drive engagement, you aren’t a “Full Stack Engineer.” You are a Grower. If you spend your time testing wild ideas that usually fail but occasionally redefine the product, you are a Prototyper.

Designers are writing code. Engineers are doing design. PMs are shipping. You are not your title. You are where your time goes.

Why the Future of Tech Teams Needs Full Stack Problem Solvers, Not Specialists

Cherny’s framework is accurate for a well-funded team like Claude Code. He notes that a pre-PMF product needs people strong at Prototyping, Building, and Sweeping, while a mature product needs Sweepers, Growers, and Maintainers.

But having spent my career in startups, I’ll add a necessary complication.

In the startup world, the future isn’t about finding five separate people to fill these archetypes. The future belongs to the Full Stack Problem Solver — the hybrid builder who can wear two or three hats simultaneously.

We don’t need a Prototyper and a Builder. We need a Prototyper who understands enough about production hardening to hand off a clean build.

We need a Builder who understands business metrics well enough to act as a Grower.

This requires a fundamental shift in how we build our careers. And here I want to be precise, because this is different from the “T-shaped” model people have been talking about for years.

The T-shape assumes breadth is secondary — a nice-to-have layer on top of your core expertise. What I am arguing is different. In the AI era, your adjacent skills are not optional extras. They are what make your core strength actually deployable in the real world.

As I wrote in The Token Test, the most valuable engineers of this era are what I called the Business Engineer — someone with deep technical capability combined with genuine business acumen. They understand which metric the feature they are building is going to move. They have a taste for design without needing to be the designer. They know the product well enough to architect solutions that don’t just work, but actually drive growth.

That is the model. Know your archetype deeply. Then build the adjacent skills that make you dangerous across the full problem space — not a generalist, not a pure specialist, but someone who can operate from their core strength and reach far enough into adjacent territory to solve real problems end to end.

If your core is Prototyping, you don’t need to become a Maintainer. But you do need to understand business logic, rapid deployment, and what good design feels like. That combination is what makes you irreplaceable.

Why Taste and Systems Thinking Are the Highest-Leverage Skills in the AI Era

This brings us to the ultimate differentiator in the role collapse era: Taste.

We usually think of taste as aesthetics — knowing what looks good. But in an era where AI can generate infinite variations of a UI, aesthetics are commoditized. Real taste, as the Codex team defines it, blends aesthetics with systems thinking.

Taste is the ability to answer the hardest question in tech right now: “If we can build anything, what should this be?”

It’s knowing the direction, the theme, and how to present an idea. It’s the Forward Deployed Engineer who sits on a messy factory floor, ignores the client’s request for a dashboard, and realizes they actually need an automated routing system. Taste is not a soft skill. It is the highest-leverage skill left.

How to Identify Your Archetype and Build Adjacent Skills to Stay Relevant

The tech industry is in an awkward transition. HR departments are still posting jobs for “Senior React Developers,” but engineering leaders are quietly looking for Builders and Sweepers.

Here’s how to position yourself:

Look at your last month of work. Where did your dots land? Own that archetype — even if it doesn’t match your official title. Then identify the two adjacent skills that would make you significantly more valuable in that archetype. If you’re a Builder, learn the product metrics that make you a Grower. If you’re a Maintainer, learn the architectural patterns that make you a Sweeper.

The role collapse isn’t something to fear. For years, builders who didn’t fit neatly into “Software Engineer” or “Product Manager” boxes were treated as organizational anomalies. Today, those anomalies are the ones building the future.

Figure out which archetype you are. Build your adjacent skills. Stop worrying about the org chart.

References

[1] Boris Cherny on X (June 28, 2026)

[2] Lenny Rachitsky on X: Takeaways from Codex Lead AJ Ambrosino (2026)

Last year, I wrote a comprehensive guide on how to select the right AI agentic framework. We talked about AutoGen, CrewAI, and LangGraph. It’s been almost a year and a half, and the industry has completely shifted.

We’ve moved past the framework era. Now, it’s all about the harness.

The reality is, the same underlying LLM can perform vastly differently depending on the harness it runs inside. A model that struggles to build a simple web app in one environment might ship a complex full-stack application flawlessly in another. The model provides the raw intelligence, but the harness provides the control, the memory, and the execution environment.

In this article, we’ll break down exactly what an agent harness is, how it differs from a framework, and look at the top 10 harnesses - both closed and open-source - that you should know about right now.

Do check out my previous articles and stay subscribed to learn more about AI, Agents, and productivity

Subscribe now

What Is an Agent Harness? (And How It Differs from Agent Framework)

These two terms get used interchangeably. They shouldn’t.

Agent Frameworks: You Build It

A framework - LangChain, LlamaIndex, AutoGen - is a software library. It hands you the raw building blocks: model abstractions, tool-calling primitives, memory modules. You write the code that connects them. You figure out what happens when a model hallucinates a tool call, how to manage state between turns, and how to recover from a failed API request.

Frameworks offer maximum flexibility. They also require significant engineering effort before anything reliable runs.

Agent Harnesses: You Configure It

A harness is the application-layer scaffolding that turns a model into a functional agent. The plumbing is already connected. You configure it, point it at your tools, and run.

A solid harness handles 4 Major building blocks - that frameworks leave to you:

Core

Model — The reasoning engine at the centre of the harness. Every decision, plan, and response flows from here. The harness exists to make it reliable.

Agent Loop — The Plan → Act → Observe cycle that runs automatically. The model doesn’t manage its own iteration. The harness does.

Execution

Tools — The actions the agent can take: Bash, Read, Write, Edit, Web Search, Browser. The harness exposes them, dispatches them, and handles what comes back.

Sandbox — The isolated runtime where tools execute safely, away from your live systems. Pre-installed runtimes, Git, and test CLIs come ready out of the box.

Filesystem + Git — Durable state for the agent. The filesystem is where it reads, writes, and offloads work. Git gives it versioning, rollback, and a shared surface for multi-agent coordination.

Intelligence

Memory — How the agent retains knowledge across sessions through files like AGENTS.md and CLAUDE.md. Without it, every session starts from zero.

Context Engineering — How the harness manages the model’s context window. Compaction summarises old history. Tool-call offloading moves large outputs to the filesystem. Progressive disclosure reveals tools only when needed.

Skills & Prompts — Task-specific instructions and conventions injected into the agent’s context. Every rule in a good AGENTS.md traces back to a real failure someone saw.

Subagents — The ability to spawn specialised agents for subtasks - a planner, an executor, a tester - and merge their results back into the main thread.

MCP — The Model Context Protocol. The standard interface for connecting the harness to external tools, data sources, and services beyond its built-in toolset.

Governance

Guardrails — Safety controls that block irreversible actions - deleting data, sending messages, making purchases - without human approval.

Observability — Logs, traces, cost metering, and latency tracking. Tells you what the agent did, how long it took, and exactly where it failed.

The Top 10 Agent Harnesses in 2026

1. Claude Code (Anthropic’s Terminal Harness)

Website: code.claude.com
Open Source: No
SDK: Yes — Claude Agent SDK
Desktop App: Yes — claude.com/download
Launched: February 2025

When Anthropic launched Claude Code in February 2025, it set a new benchmark for what a terminal agent could do. Available via the terminal, the desktop app, and in the cloud, Claude Code is a complete harness ecosystem rather than a single tool. Anthropic also released the Claude Agent SDK, which lets developers build custom applications using the exact same harness infrastructure that powers Claude Code itself.

The harness handles context engineering automatically - compressing long sessions, managing tool results, and keeping the model oriented across complex multi-step tasks. If you want to see it in action, my guide on building a Claude-Managed AI Agent walks through the full setup.

2. Codex (OpenAI’s Agentic Harness)

Website: openai.com/codex
GitHub: github.com/openai/codex
Open Source: CLI is open source (Apache 2.0) — 92,334 stars
SDK: Yes — OpenAI Agents SDK
Desktop App: Yes — developers.openai.com/codex/app
Launched: April 2025 (CLI); February 2026 (Desktop App)

OpenAI launched Codex CLI in April 2025 as an open-source terminal agent, then followed up with the Codex Desktop App in February 2026. The CLI is open source and available on GitHub. The full Codex platform and harness infrastructure are closed.

OpenAI’s harness engineering focuses on bidirectional communication between the model and the execution environment - ensuring reliable streaming progress and clean tool execution across long-running tasks. The Codex Desktop App also integrates with ChatGPT mobile, so you can hand off tasks between devices.

I find Codex Desktop to be damn good in comparison to Claude Cowork in terms of User experience.

3. Cursor

Website: cursor.com
Open Source: No
SDK: Yes — Cursor SDK (TypeScript + Python)
Desktop App: Yes — cursor.com/download
Launched: April 2026 (SDK Beta)

Cursor made a deliberate bet on harness infrastructure when it released the Cursor SDK in April 2026. The SDK lets developers build agents directly on Cursor’s harness - model-agnostic, deployable from CI/CD pipelines or backend services.

Benchmarks have shown the same model scoring noticeably higher on coding tasks when running inside Cursor’s harness versus other environments. The harness is doing real work here, not just passing prompts through.

4. Pi

Website: pi.dev
GitHub: github.com/earendil-works/pi
Open Source: Yes (MIT License) — 64,296 stars
SDK: Yes — npm package
Desktop App: Yes — pi.dev
Launched: August 2025

Pi is fully open source and one of the most minimal agent harnesses available. The biggest advantage is customizability. You can tailor the harness to your own workflows and company style - and share those configurations with others through extensions. You don’t adapt your workflow to Pi; Pi adapts to you.

Pi ships with a deliberately focused toolset: Read, Bash, Edit, Write, Find, and LS.

No bloat, no unnecessary MCP integrations by default. You extend it with your own skills, prompt templates, and themes, then bundle those extensions to share with your team. For teams that want a consistent, opinionated agent environment without the overhead of a larger platform, Pi is hard to beat.

Pi was also one of the foundational inspirations behind OpenClaw. If you’ve followed my coverage of OpenClaw, you’ll recognize the same philosophy: give a powerful agent a clean, minimal surface to work from.

5. OpenCode

Website: opencode.ai
GitHub: github.com/anomalyco/opencode
Open Source: Yes (MIT License) — 176,675 stars
SDK: Yes
Desktop App: Yes (Beta) — opencode.ai/download
Launched: April 2025

OpenCode is the most-starred open-source coding agent of 2026, crossing 150,000 GitHub stars within months of launch. It’s a full-featured terminal harness with two built-in agents you can switch between - a default build agent with full access, and a read-only plan agent for scoping work before executing it. OpenCode also ships with its own SDK for building custom applications on top of the harness, and a desktop app in beta across macOS, Windows, and Linux.

6. OpenHands

Website: openhands.dev
GitHub: github.com/All-Hands-AI/OpenHands
Open Source: Yes — 77,852 stars
SDK: Yes
Desktop App: Yes — openhands.dev
Launched: March 2024

OpenHands - formerly OpenDevin - is one of the most complete open-source agent harnesses available. It provides a full platform for building agents that interact with code, terminals, file systems, and web browsers. It ships as a desktop app, CLI, and API. OpenHands is particularly strong for teams that want to run self-hosted, always-on engineering agents without paying for a managed platform.

7. Cline

Website: cline.bot
GitHub: github.com/cline/cline
Open Source: Yes (Apache 2.0) — 63,573 stars
SDK: Yes
Desktop App: No — IDE Extension and CLI only
Install: cline.bot
Launched: July 2024

Cline operates as an SDK, an IDE extension, and a CLI assistant - trusted by 8 million developers. It features robust Plan/Act modes and deep MCP integration, making it one of the most extensible open-source harnesses available. Cline doesn’t have a standalone desktop app; it lives inside your editor. For developers who spend most of their time in VS Code, that’s not a limitation - it’s where they already are.

8. Goose.ai

Website: goose-docs.ai
GitHub: github.com/aaif-goose/goose
Open Source: Yes — 49,930 stars
SDK: Yes
Desktop App: Yes — goose-docs.ai
Launched: January 2025

Developed by Block’s Open Source Program Office, Goose is a general-purpose AI agent that runs locally on your machine. It handles research, writing, automation, and data analysis - not just code. Goose ships with a desktop app, CLI, and API, and connects with tools and services through extensions. For builders who want an open-source harness that works across more than just a code editor, Goose is one of the few that delivers on that promise.

9. Mastra

Website: mastra.ai
GitHub: github.com/mastra-ai/mastra
Open Source: Yes — 25,280 stars
SDK: Yes
Desktop App: No — Local Studio UI
Studio: mastra.ai/docs/studio

Launched: October 2024 (framework); June 2026 (Mastra Harness)

Mastra is a modern TypeScript framework that formally announced its Harness primitive in June 2026.

It lets you build interactive AI agents with multiple modes, persistent threads, tool approvals, and model switching - all within a TypeScript-native environment. Mastra doesn’t ship a standalone desktop app, but its local Studio UI gives you a full visual interface for building, testing, and managing agents during development. Strong choice for TypeScript teams that want production-ready harness infrastructure with observability built in from day one.

10. Deep Agents (LangGraph)

Website: docs.langchain.com/oss/python/deepagents/overview
GitHub: github.com/langchain-ai/deepagents
Open Source: Yes (MIT License) — 24,870 stars
SDK: Yes
Desktop App: No — CLI and SDK only
Launched: July 2025

Built by the LangChain team on top of the LangGraph runtime, Deep Agents is an opinionated, batteries-included harness for long-running, multi-step tasks. It ships with built-in planning, task delegation via subagents, and automated context engineering. No desktop app - this one is built for developers who want to run agents from scripts, pipelines, and backend services. If you’re already deep in the LangChain ecosystem, Deep Agents is the natural next step toward production-grade agentic workflows.

What Are Meta-Harnesses - And Why They’re the Next Big Thing

As teams start using multiple harnesses simultaneously, a new category has emerged: the meta-harness. These tools let you run Claude Code, Codex, Pi, and others within a single unified environment - keeping sessions, policies, and skills consistent regardless of which underlying harness is doing the work.

Omnigent by Databricks is the most prominent example right now. Open-source under Apache 2.0 and launched in June 2026, it sits above the tools you already use, providing a shared orchestration layer for composition, governance, and collaboration.

Vercel AI SDK v7 introduced the HarnessAgent API in June 2026, providing a single programmatic interface for running Claude Code, Codex, and Pi from one codebase.

The meta-harness category is early, but the direction is clear. Teams that run multiple harnesses will want a single control plane. That’s what meta-harnesses provide.

Are Agent Harnesses Only for Coding? Not Anymore

The coding agent conversation dominates the headlines, but the harness architecture works for any domain where an agent needs to plan, act, and recover across multiple steps.

In customer service automation, harnesses manage the full state of a customer interaction - querying internal databases, executing refunds, and escalating edge cases, all within a controlled execution environment.

In data analysis and research, agents autonomously query data warehouses, run statistical models, and compile research reports over hours or days without losing context.

In business process automation, harnesses are replacing rigid RPA workflows with agentic systems that handle exceptions and edge cases without human intervention.

The pattern is the same across all three: the model provides the reasoning, and the harness provides the reliability.

Which Agent Harness Should You Pick?

Stop obsessing over which foundational model to use. The models will continue to leapfrog each other every few months - that race never ends.

The harness is where the real leverage is. It determines how reliably your agent executes, how well it recovers from failure, and how much engineering you need to maintain it. A great harness makes a good model look excellent. A poor harness makes an excellent model look unreliable.

If you want the most complete closed-source experience, Claude Code or Codex is the benchmark.

If you want open-source flexibility with the largest community, OpenCode is where the momentum is.

If you want minimal and customizable, Pi is the one to build on. I prefer this.

And if you’re a TypeScript team building production agents, Mastra just shipped exactly what you need.

Pick your harness. Configure your tools. Let the agent do the work.

Start building your agents and your workflows.

Related reading: How to select the right AI Agentic Framework · Building a Claude-Managed AI Agent · OpenClaw: Setup Guide

If you read my recent article on Why I Switched from OpenClaw to Hermes Agent, you know that one of the biggest advantages of Hermes is its simplicity.

Until recently, running autonomous AI agents required significant command-line experience, environment variable configuration, and constant troubleshooting. With the release of Hermes Desktop, that barrier to entry has vanished.

You can now get a self-improving, autonomous AI agent running on your Mac or Windows machine in under 5 minutes. Here is the complete step-by-step guide to setting up Hermes Desktop, complete with screenshots from my own installation process.

If you would like to explore Skills, Agents, etc… check out the articles below:

Subscribe now

Step 1: Download the Installer

First, navigate to the official Hermes Agent website. You will be greeted by their distinctive electric blue landing page.

Click the Download for Mac OS (or Windows) button. The site will automatically detect your operating system. If you need a different version, click the “Install” link in the top navigation to see all available options.

Step 2: Run the Setup Wizard

Once the download completes, run the installer just like any standard application. When you launch Hermes for the first time, you will see the welcome screen.

Click Install Hermes →. The application will spend a few minutes downloading the necessary dependencies and setting up the agent environment in the background.

You do not need to open a terminal or run any pip install commands—the desktop app handles everything across 11 automated steps, including setting up the Python environment, downloading browser tools, and configuring default skills.

Once it says “HERMES IS READY,” click Launch Hermes.

Step 3: Configure Your Providers (API Keys)

Now you need to give Hermes a “brain” by connecting it to an AI model provider.

Hermes is provider-agnostic. While Nous Portal is recommended, you can click on Other providers to see options like OpenAI, MiniMax, Qwen, or xAI.

Because autonomous agents consume a significant amount of tokens, I highly recommend using open-source models to keep costs down. I personally use OpenCode Go , which gives you access to powerful models like MiniMax 3 and GLM 5.1 at a fraction of the cost of frontier models.

If you choose a provider like OpenAI, you’ll be taken through a standard OAuth flow.

Once connected, you will drop into the main Hermes chat interface.

You can immediately start chatting with your agent right here in the desktop app.

Step 4: Connect Telegram (Messaging Gateway)

One of the best features of Hermes is that it “lives everywhere.” You can communicate with it via Telegram, Discord, Slack, or WhatsApp.

I highly recommend setting up Telegram so your agent is reachable from your phone 24/7.

In Hermes Desktop, navigate to Messaging in the left sidebar and select Telegram.

Follow these steps to get your credentials:

1. Open Telegram on your phone or desktop

2. Search for @BotFather and start a chat

3. Send the command /newbot

4. Follow the prompts to name your bot and get your HTTP API Token

5. Back in Hermes Desktop, paste this token into the Bot token field.

6. Crucial Security Step: You need to restrict access so only YOU can talk to your agent. In Telegram, search for @userinfobot and start a chat. It will reply with your numeric Id.

7. Copy that ID and paste it into the Allowed Telegram user IDs field in Hermes. Click Save changes.

You should now see blue “Connected” and “Credentials set” badges at the top of the Telegram settings page.

Step 5: Test Your Agent in Telegram

Now that everything is connected, open your newly created bot in Telegram and send a /start or hi message.

The agent will respond! It will also ask you to type /sethome if you want this chat to be the primary channel where it delivers automated cron job results.

Back in Hermes Desktop, you will see this Telegram conversation appear in your Sessions list.

Bonus: Skills, Voice, and Profiles

Once the basics are set up, you can explore Hermes’ advanced features:

Skills & Tools: Navigate to the Skills tab to enable over 70 pre-built capabilities, from Apple Notes integration to GitHub repository management.

Multiple Profiles: If you want different agents for different tasks (e.g., a research agent vs. a coding agent), click the + button at the bottom left to create isolated profiles with their own specific instructions (SOUL.md).

Next Steps: Moving to the Cloud

Running Hermes on your desktop is the perfect way to get started. But once you have your workflows dialed in, you will likely want your agent running 24/7 without keeping your laptop open.

Because Hermes saves its work and memory to disk, migrating is easy. You can deploy it on a $5/month VPS using Railway . Just zip up your ~/.hermes/guides/ folder and drop it into your remote server, and your agent will pick up right where it left off.

If you want to see exactly how I use Hermes to run TheToolNerd, check out my full review: I Tested Hermes Agent for a Week — Here’s Why I Switched from OpenClaw.

When I first set up OpenClaw a few months ago, I built a 7-agent “Mission Control” system to run TheToolNerd. I had agents researching tools, monitoring social media, and preparing my daily briefings. It felt like the future. But the reality of running it daily was different.

Updates broke my configurations. The agent’s memory got bloated so quickly that I burned through my OpenAI credits. And worst of all, the agents would forget what I taught them. I’d ask them to do the same task twice and they’d make different mistakes both times.

I needed an assistant, not a second job.

I had been hearing about Hermes Agent for a while.

The promise was compelling: an agent that actually learns from experience, creates its own guides, and doesn’t forget them the next day.

A couple of weeks ago, I finally made the switch. Here is my honest assessment of Hermes Agent, how it compares to OpenClaw, and why it is now running my operations.

Do check out my previous articles

Subscribe now

What is Hermes Agent? (And Why It’s a Different Kind of AI Agent)

Hermes Agent is an open-source tool built by Nous Research, a lab that builds AI models. Unlike other agent tools that just wrap existing APIs, Hermes is designed from the ground up to learn and improve over time.

Unlike OpenClaw, which focuses on orchestrating teams of specialized agents, Hermes is a single agent that runs a persistent learning loop. It does not just log what happened; it extracts what worked, writes it as a reusable guide, and loads it the next time you need it.

It lives wherever you put it. You can run it locally or drop it on a $5 VPS. You communicate with it through Telegram, Discord, Slack, or your terminal, while it works quietly in the background.

Why I Switched: The OpenClaw Reality Check

My previous experience with OpenClaw taught me a lot about what I actually needed from an agent framework. OpenClaw is powerful for building complex, multi-agent systems. If you need a Slack agent, an email agent, and a research agent all talking to each other, OpenClaw is the right tool.

But for my workflow, the architecture created more problems than it solved.

The Reliability Problem.

Even after carefully defining instructions and guides, OpenClaw failed often. I would ask it to run my tool approval workflow, and it would make up steps or get stuck. I had to constantly redo the work or reteach it the process.

The Context Bloat & Memory Problem

OpenClaw’s memory system is rich but gets bloated. It drags old, irrelevant conversations into new tasks. Even after reteaching it a guide and explicitly asking it to update its memory, it would somehow lose track and fail to execute the work as expected.

The Skyrocketing Cost Problem

Frontier models (like GPT-5.5, Claude) consume massive amounts of tokens when running multi-agent systems. The token usage was unsustainable. I had to switch to open-source and open-weight models via OpenCode Go (referral link), which gave me access to models like MiniMax 3 and GLM 5.1 at a fraction of the cost.

The Hermes Advantage: A Self-Improving AI Agent That Actually Learns

Hermes approaches these problems differently. It is not trying to be a whole organization of agents. It is trying to be one extremely competent operator that gets better at your specific workflows over time.

Autonomous Guide Creation from Real Experience

The most significant difference is how Hermes handles guides. In OpenClaw, guides are static. You write them, deploy them, and hope they work.

Hermes creates guides autonomously. When it completes a complex task—such as recovering from an error or executing a tricky workflow—it automatically records what it did. The next time you ask for something similar, it uses that written guide instead of figuring it out from scratch. It even improves these guides as it uses them.

Lean, Search-First Memory That Eliminates Context Bloat

Hermes keeps its memory lean and fast. Instead of dragging everything into every conversation, it separates:

• Core Instructions (things it needs to know every time)

• Past Conversations (which it searches only when relevant)

• Guides (which it loads only when needed)

This prevents the bloat that slowed down OpenClaw. An agent with 200 guides pays roughly the same memory cost as one with 40, because detailed guide content only enters the conversation when actually needed.

Hands-On Testing: Automating the ToolNerd Approval Workflow

The real test was my ToolNerd approval workflow. This is a complex, multi-step process that OpenClaw struggled with consistently.

The workflow requires the agent to:

1. Query my Supabase database for unapproved tools

2. Check if the screenshot, logo, and favicon are valid

3. If assets are missing or broken:

• Navigate to the official website

• Download the icon

• Upload it to Supabase storage

• Take a screenshot

• Update the database record

OpenClaw hallucinated steps and made errors most of the time on this workflow.

I exported my guides from OpenClaw as a zip file and fed them directly to Hermes. Hermes imported them seamlessly. When I ran the workflow, it executed smoothly on the first try. I monitored it every day for a week, and it consistently performed the task without intervention. The only hiccup occurred when my API credits ran out, requiring a simple retry command.

That consistency is the thing. OpenClaw would work once, then fail the next day. Hermes just kept running.

Setup and Deployment: Why Hermes is Surprisingly Simple

OpenClaw has a notoriously fragile setup process. Every update seems to break a configuration file or wipe out environment variables.

Hermes is significantly easier to deploy. I set it up on Railway in minutes.

Setting up a single communication channel via Telegram was straightforward. I did face some initial challenges setting up multiple profiles and bots for my more experimental workflows. But once configured, the ability to have multiple profiles—essentially an army of agents sharing the same environment, guides, and memory—proved incredibly powerful. I now have dedicated agents managing different Telegram topics without any cross-contamination.

Head-to-Head Comparison: Hermes Agent vs OpenClaw

Pros & Cons: My Honest Assessment of Both Frameworks

Where Hermes Agent Excels

Hermes autonomously learns and improves workflows from experience, which is the single biggest differentiator from every other agent framework I have tested. It keeps memory lean and fast, preventing the bloat that slowed down OpenClaw. It runs smoothly on low-cost VPS infrastructure without the constant maintenance burden. And the real-time emoji-mapped tool usage in Telegram makes it transparent—you always know what it is doing and can interrupt it mid-task.

Where Hermes Agent Still Falls Short

The multi-agent architecture uses a parent-subagent model rather than persistent communicating teams, which makes it weaker for complex coordination scenarios. Configuring multiple profiles and bots takes trial and error. The guide marketplace is smaller compared to OpenClaw’s ClawHub, though the agentskills.io open standard means guides are portable across compatible agents.

The Final Verdict: Which AI Agent Framework Should You Choose?

Both frameworks have their place in the evolving AI agent ecosystem. The choice comes down to your actual workflow.

Choose OpenClaw if you are building a complex, multi-channel control plane. If you need dedicated agents monitoring Slack, Discord, and email simultaneously, and you need those agents to collaborate with persistent state, OpenClaw’s architecture is built for that. It also has a larger marketplace of pre-built guides.

Choose Hermes Agent if you want a personal runtime that handles recurring automation and improves over time. If your workflows involve daily reports, research loops, data collection, or complex repetitive tasks like my tool approval process, Hermes is the clear winner.

Hermes feels leaner, more transparent, and significantly more reliable for the work I do. The fact that it actively learns from my corrections and builds its own procedural memory makes it feel less like a brittle script and more like an actual assistant.

OpenClaw has a ton of features and a vibrant community. Hermes is catching up and is a strong contender. As a legitimate company with a dedicated team building it, I am more confident in Hermes’ trajectory than I am in OpenClaw’s.

Ready to Make the Switch?

If you are dealing with bloated context windows, skyrocketing API costs, and agents that suffer from amnesia, Hermes Agent offers a compelling alternative.

With the recent release of Hermes Desktop, the barrier to entry is lower than ever. You no longer need to be a command-line expert to get an autonomous agent running on your machine.

I’ve watched the social media take on Microsoft and Uber’s AI pullback spread like wildfire. The narrative goes something like this: “Big tech companies are realizing AI is too expensive. They’re cutting costs, shutting down AI coding tools, and going back to hiring normal developers. The AI hype is over.”

This narrative is wrong. It misunderstands the core economics of what is actually happening.

Companies are not retreating from AI. They are retreating from unmetered AI - the phase where nobody tracked costs and everyone assumed the bill would sort itself out. What we are seeing now is a shift from reckless experimentation to strategic discipline.

And the economic principle driving this entire shift - the reason why falling AI costs are paradoxically causing enterprise budgets to explode - is a 160-year-old concept called the Jevons Paradox.

If you want to understand why small, founder-led agencies are positioned to win the next five years while enterprises scramble to fix their procurement models, you need to understand this paradox.

You can check out my previous articles to learn more about AI and AI trends

Subscribe now

The Enterprise AI Cost Crisis: Why "TokenMaxxing" Broke the Bank

The Unmetered AI Trap: How Uber and Microsoft Burned Millions

In April 2026, I wrote about The Token Test - explaining why “TokenMaxxing,” where engineers compete on internal leaderboards to consume the most AI tokens, was a vanity metric destined to fail.

That failure arrived faster than expected.

Microsoft cancelled most of its internal Claude Code licenses in its Experiences & Devices division just six months after launching them.

Uber burned through its entire 2026 AI coding budget in just four months - Claude Code adoption jumped from 32% to 84% of their 5,000 engineers, with individual developers spending up to $2,000 per month on tokens.

One unnamed enterprise reportedly spent $500 million in a single month because they failed to set usage limits on their licenses.

The problem is not that the tools don’t work. The problem is that the tools work too well, and the pricing model is fundamentally broken for knowledge work.

When you charge for AI by the token, and you give engineers agentic tools that run autonomous loops, a single request can generate thousands of inference calls. Enterprises handed their teams a corporate credit card with no limit, tied to a metered utility that runs while nobody is looking.

But here is the real puzzle: how did costs explode exactly when the price of AI models collapsed?

What is the Jevons Paradox in AI?

In 1865, English economist William Stanley Jevons published The Coal Question. He observed something counterintuitive: as steam engines became more fuel-efficient, Britain didn’t use less coal. It used far more.

The logic was simple. More efficient engines lowered the cost of doing work with coal. Lower costs made coal-powered applications viable in more industries. More industries adopted steam power. Total coal consumption skyrocketed.

We saw this with cars - better fuel efficiency led to more driving. We saw this with computing - cheaper storage led to massive data hoarding. Now, we are seeing it with AI tokens.

The AI Cost Collapse: Real Token Pricing in 2026

Here is how dramatically the model pricing landscape has shifted in just three years. GPT-5.5 - OpenAI’s current flagship - costs $5 input / $30 output per million tokens. Claude Opus 4.8 - Anthropic’s latest - sits at $5 input / $25 output. Compare that to GPT-4 in 2023 at $15 input / $60 output, and the collapse is stark.

That is an 80-95% price drop depending on the tier you compare.

Why Cheaper AI Models Drive Total Spending Up

According to standard logic, companies should be spending far less on AI. But that is not what happens when the Jevons Paradox kicks in.

When Claude Opus cost $75 per million tokens, you only used it for high-value tasks. At $25 per million - or $0.40 for DeepSeek - the calculus changes completely. Now it is economically rational to run AI analysis on every customer support ticket, generate first drafts of every internal document, and process every data record in your database.

This is why Goldman Sachs projects that token consumption will multiply 24x by 2030. It is why Google processed 3.2 quadrillion tokens in May 2026 alone - a 7x jump from the previous year.

Subscribe now

Token Economics: Why the Social Media Narrative Has It Wrong

This brings us back to the narrative that companies are “moving away” from AI.

When Uber’s engineers burn $2,000 a month each, the company isn’t going to take the AI away and tell them to code manually again. The productivity loss would be catastrophic. Instead, the procurement model is shifting.

We are moving toward a world of metered access, hard budget caps, and eventually, flat-fee unlimited pricing. Enterprises are realizing that you cannot treat knowledge work like a metered AWS instance. You need predictable costs.

The companies that scale AI successfully over the next two years won’t be the ones that cut usage. They will be the ones that build systems to manage it.

And this is exactly why small agencies might win being more efficient.

How Lean AI Agencies Use Token Efficiency to Win

While enterprises struggle with runaway budgets and misaligned incentives, small, founder-led AI agencies are building the systems of the future.

Why? Because founders have skin in the game.

In a large enterprise, an engineer running an inefficient agent loop doesn’t pay the API bill. In a small agency, every wasted token comes directly out of the founder’s margin. This capital scarcity forces discipline. It forces the agency to build systems that exploit the Jevons Paradox rather than falling victim to it.

Here is the playbook lean AI agencies are using right now:

1. Dynamic Model Routing Strategies

Small agencies do not send every request to Claude Opus 4.8 ($25/M output tokens) or GPT-5.5 ($30/M output tokens).

They build routing systems. A simple summarization or data extraction task goes to GPT-5 Mini ($2/M tokens) or Gemini 3 Flash ($3/M tokens).

Only complex reasoning - architecture decisions, nuanced analysis, multi-step code generation - gets routed to the frontier models. This single architectural decision cuts per-request costs by 40-60% without degrading output quality.

2. Prompt and Semantic Caching

If ten users ask an AI agent similar questions, an enterprise system often processes ten identical LLM calls. A lean agency implements semantic caching at the gateway layer. The system recognizes a repeated or near-identical query and serves the cached answer, eliminating the inference cost. Anthropic’s own prompt caching feature can reduce costs by up to 90% on repeated system prompts.

3. Outcome-Based Incentives and the "First Pass Rate"

Enterprises built leaderboards rewarding engineers for consuming tokens. Lean agencies incentivize outcomes. They evaluate engineers on the “First Pass Rate” - the ability to write context so clearly that the AI executes the requirement perfectly on the first attempt, eliminating expensive redo cycles. As I described in The Token Test, this is the skill that separates the next generation of AI-native engineers from everyone else.

4. Setting Strict Inference Budgets for Autonomous Agents

Agent loops are the biggest driver of cost explosions. A poorly designed agent can get stuck in a reasoning loop, burning thousands of calls. Lean teams build hard circuit breakers and per-task inference budgets. If an agent hits $2 of spend on a single task, the system halts it and flags it for review.

The Real ROI of AI is Time Compression, Not Headcount

The fundamental mistake enterprises made was expecting AI to deliver linear cost savings. They looked at an AI coding tool and thought: this will let us fire half our engineers and save 50% on payroll.

That is not how the math works.

The real promise of AI is time compression and velocity.

The value is not cheaper code. The value is faster shipping, fewer bottlenecks, and smaller teams delivering more. Small agencies understand this intuitively. They use AI for leverage. Enterprises are still trying to use it for headcount reduction, and they are getting burned by the token bills.

The Verdict

The TokenMaxxing era is over. The days of burning tokens as a vanity metric are ending.

But AI is not retreating. Thanks to the Jevons Paradox, as models like GPT-5.5, Claude Opus 4.8, and Gemini 3 Pro get cheaper and faster, they will embed themselves deeper into every workflow, every product, and every industry. The total consumption of intelligence will only increase.

The winners in this next phase will not be the companies with the biggest budgets. The winners will be the lean, founder-led teams who understand token economics. The developers who know when to use GPT-5.5 and Claude Opus 4.8 for hard problems, and when to route everything else to the $2/M models.

The future belongs to those who can pass the Token Test.

References

[1] The Token Test - TheToolNerd: https://www.thetoolnerd.com/p/the-token-test-how-the-best-companies

[2] LLM API Pricing Comparison June 2026 - CostGoat: https://costgoat.com/compare/llm-api

[3] Best AI Models June 2026 - Overchat AI: https://overchat.ai/ai-hub/the-best-ai-model

[4] Goldman Sachs Token Consumption Projection (24x by 2030): Goldman Sachs Global Investment Research, 2025

[5] Jevons Paradox in AI - Mindstudio: https://www.mindstudio.ai/blog/jevons-paradox-ai-cheaper-models-more-jobs/

[6] Enterprise AI Cost Crisis - SmarterX: https://smarterx.ai/smarterxblog/ai-costs-exploding-at-enterprise

How I Discovered the FDE Role

I had never heard of a Forward Deployed Engineer until I joined my current organization. The term popped up casually during a discussion with the founders, and I was intrigued. What exactly was this role? Why were they talking about it so seriously?

I started digging, and then I came across this recent tweet by Mike Fishbein that was so good.

After 40+ forward deployed engineering engagements, Fishbein had distilled the role down to its essence: FDEs are three jobs in one.

They figure out where in the business to build (consulting), what to build (product), and how to build it (engineering). But more importantly, he nailed the real bottleneck: coding is now the easy part.

Everything before the code—extracting context from clients, understanding their workflows, creating structure from chaos—is the hard part.

This wasn’t just another tech role. It was a structural response to the messy reality of enterprise AI.

Check out my previous articles and subscribe to keep updated with interesting insights on AI :

Subscribe now

Why This Matters Now

If you are an engineer deciding where to invest your career in 2026, or a founder trying to figure out why your AI deployments keep stalling, you need to understand the Forward Deployed Engineer.

But here’s what makes this role particularly relevant right now: the emergence of SovereignAI.

As data sanctity and security become paramount, organisations are increasingly demanding full ownership of their AI stack—including their proprietary data, models, and organisational secrets. They don’t want their workflows locked into someone else’s cloud. They want control. They want sovereignty.

This shift fundamentally changes who gets hired and how. It’s no longer enough to have a generic “AI solution.” You need someone who can navigate the complexity of building AI systems that respect data boundaries, comply with regulations, and integrate seamlessly with legacy infrastructure. That someone is the FDE.

Two Paths Into the FDE Role

The beauty of the FDE role is that it’s not gatekept by a single background. There are two distinct paths in.

If you’re a generalist, you can transition into the FDE role if you can become genuinely good at AI and technology. You don’t need a decade of engineering experience. You need to understand how AI works, how to prototype quickly, and how to communicate technical concepts to non-technical stakeholders. Your business intuition becomes your superpower. You already understand how organisations work. Now learn the tech.

If you’re a techie, the path is different but equally viable. You can learn about the business world, real-world problem-solving, and how to think beyond coding in silos. Most engineers spend their careers optimising for technical elegance. FDEs optimise for customer outcomes. That’s a mindset shift more than a skill gap. Learn to ask “why” before “how.” Understand the business impact of every line of code. Transition from builder to builder-for-a-purpose.

Both paths converge at the same place: someone who can navigate ambiguity, own customer outcomes, and bridge the gap between what’s technically possible and what’s business-critical.

Understanding the FDE: The Three Jobs in One

The term “Forward Deployed Engineer” sounds like a purely technical role. It’s not. As Fishbein points out, an FDE is actually three distinct jobs wrapped into one high-stakes position [1].

First, they act as consultants. They figure out where in the business to build. They map real-world workflows, talk to stakeholders across different departments, and identify the highest-value opportunities for AI integration. They do the organisational discovery that traditional product teams rarely have time for.

Second, they act as product managers. They decide what to build. They define the scope, prioritise features, and crucially, feed their field insights back to the core product team at headquarters.

Third, they are engineers. They figure out how to build it. They write production-grade code, deploy systems, and navigate the labyrinth of legacy infrastructure and fragmented data pipelines that define modern enterprise environments.

Coding is now the easy part, thanks to tools like Claude Code and Cursor. The hard part is everything before the code. It is extracting context from clients who have it scattered across people and tools, and creating context when it doesn’t exist at all.

The Origin Story: How Palantir Invented the FDE Role

The FDE role didn’t emerge from the AI boom. It was born out of necessity in the early 2010s at Palantir Technologies [2].

Palantir faced a problem that traditional software companies never encounter. Their early customers were intelligence agencies. These organisations couldn’t openly share their data, their workflows were constantly changing, and they often couldn’t clearly explain what they needed.

Traditional product development—gathering requirements, building in isolation, and shipping a final product—was useless.

So Palantir did something unusual. They embedded their engineers directly inside customer environments. These engineers learned by observing, experimenting, and building in real time. Palantir called these early embedded engineers “Deltas.”

This created the “gravel road to paved highway” feedback loop. FDEs would build rough, custom solutions for specific customers (the gravel roads). The core engineering team back at HQ would study these solutions, find patterns across multiple clients, and build standardised features into the main platform (the paved highways).

The model worked so well that by 2016, Palantir had more forward-deployed engineers than traditional software engineers [2]. Today, Palantir’s Q1 2026 results show 85% year-over-year revenue growth and 133% growth in U.S. commercial business—proof that the FDE model is not just viable, but highly profitable [3].

Why Forward Deployed Engineers Are Exploding in 2026

The Enterprise AI Bottleneck

Fast forward to 2026. Why are FDE job listings spiking by 800%? [4]

Because AI systems face the exact same challenges Palantir faced fifteen years ago. AI is complex, undefined, and highly contextual. No single solution works everywhere, and most companies struggle to define exactly what they need from AI.

A 2025 MIT report found that about 95% of enterprise generative AI pilots showed no measurable profit and loss impact. The researchers traced this failure not to weak models, but to flawed integration. The bottleneck was not model capability but the gap between a polished demo and a working integration inside legacy systems, change advisory boards, and compliance regimes that move at their own pace [3].

When you deploy a deterministic SaaS product, you configure it. When you deploy an AI agent, you have to adapt it to the probabilistic, judgment-heavy reality of human workflows.

OpenAI’s $4 Billion Bet on Deployment

OpenAI realized this early. On May 11, 2026, they announced the OpenAI Deployment Company—a major structural bet on the FDE model [5].

The company launched with more than $4 billion in committed capital, led by TPG with co-lead founding partners including Advent, Bain Capital, and Brookfield. In connection with the launch, OpenAI acquired Tomoro, an Edinburgh-based AI consulting and engineering firm, bringing approximately 150 experienced Forward Deployed Engineers and Deployment Specialists to the OpenAI Deployment Company from day one [5].

This is not a side project. OpenAI’s enterprise customers already account for more than 40% of OpenAI’s revenue, with the company expecting parity with consumer revenue by year-end 2026. That mix only holds if pilots convert to production, and OpenAI has concluded that conversion does not happen without engineers on the ground [3].

The Broader Industry Pattern

OpenAI is not alone. In a 13-week run of deployment-heavy enterprise announcements in early 2026:

• February 23: OpenAI announced its Frontier Alliance, pairing its Forward Deployed Engineering team with McKinsey, Boston Consulting Group, Accenture, and Capgemini [3].

• May 4: Anthropic announced a joint venture valued at more than $1.5 billion with Blackstone, Hellman & Friedman, and Goldman Sachs that embeds its engineering resources inside a standalone enterprise services firm [3].

• May 11: OpenAI announced the OpenAI Deployment Company with $4+ billion in capital and the Tomoro acquisition [5].

• May 2026: Meta reportedly launched a new Enterprise Solutions unit that will embed engineers and product managers inside corporate customers to push them toward its AI tools [3].

The two ventures together—OpenAI’s and Anthropic’s—put approximately $5.5 billion behind AI deployment and enterprise services [3].

Forward Deployed Engineer vs. Other Technical Roles

It is easy to confuse FDEs with other customer-facing technical roles. The distinction comes down to ownership and product impact.

A Sales Engineer sells the dream.

A Solutions Architect designs the blueprint. A core Software Engineer builds the toolbox.

The Forward Deployed Engineer uses that toolbox to build the custom, finished solution on the client’s messy construction site.

The FDE Work Loop: What You Actually Do Every Day

The work of an FDE follows a relentless four-stage loop.

They start with scoping. A customer presents a vague problem— “We want to use AI in our factory.” The FDE digs in, finds the real bottleneck, and defines a concrete technical plan.

Next comes prototyping. They move fast, building a proof-of-concept to show the customer what is possible and gather immediate feedback.

Then comes deployment. They harden the code, make it scalable and secure, and navigate the client’s infrastructure to get it live.

Finally, feedback. They take the insights they’ve gathered on the front lines and bring them back to the core product team, ensuring the platform evolves based on real-world friction.

It is a high-stress, high-impact role. You might spend 25-50% of your time travelling, working in unconventional environments from factory floors to airgapped defence installations. The ownership mentality required is absolute.

Forward Deployed Engineer Salary: Authentic Data from Job Portals and Reports

Glassdoor Data (609 Submissions, June 2026)

According to Glassdoor’s aggregated salary data, the FDE market shows significant variation by experience level and company [6]:

• Average total compensation: $155,711 per year

• Typical range: $124,407 (25th percentile) to $197,984 (75th percentile)

• Top earners (90th percentile): $243,785 per year

• Top paying industry: Information Technology at $134,925 median

• Top paying companies: Palantir Technologies, C3 AI, ActionIQ

Recruiting from Scratch Analysis (135 Active Job Postings, May 2026)

Recruiting from Scratch analyzed 135 real FDE job postings and found [7]:

• Median base salary: $190,000

• Range: $160,000 (25th percentile) to $220,000 (75th percentile)

• Geographic premium: San Francisco median of $192,000 is 7% higher than remote median of $180,000

• Experience-based breakdown:

  • Entry-level (3-5 years): ~$160,000

  • Senior (5-8 years): ~$190,000

  • Staff/Principal (8+ years): $220,000+

Perspective AI Report: The Definitive 2026 FDE Compensation Study

Perspective AI synthesized 1,200 FDE compensation data points from Levels.fyi, public job postings, and pay-transparency disclosures, revealing a bifurcated market [8]:

Frontier Labs (OpenAI, Anthropic):

• Mid-level: $385K total compensation

• Staff-level: $610K total compensation

• Principal: $1.0M+ total compensation

• Equity: 60-70% of total comp (up from 35-45% in 2024)

• Equity structure: RSUs on private stock, 4-year vest, 1-year cliff, liquidity via annual secondary tender offers

Applied-AI Startups (Series B-D):

• 30-40% less than frontier labs in total comp

• Higher early-stage equity upside potential

• 4-year vest, 1-year cliff

Palantir FDSE (Public Company):

• Median total compensation: $215K

• Base salary: $135,000-$200,000

• Equity: RSUs on public PLTR stock (immediately liquid on vest)

• Bonus: 15-25% of base, often tied to delivery and customer-expansion metrics

Fortune 500 / Big Banks:

• Base: $190,000-$420,000

• Equity: 15-25% of total compensation

• Low-multiplier upside compared to frontier labs

Key Finding: Equity now represents 55-70% of compensation at frontier labs, up significantly from 35-45% in 2024. The entire comp gap between Palantir ($215K median) and frontier labs ($385K+ mid-level) sits in equity [8].

Forward Deployed Engineer Job Openings at Major Companies (May 2026)

OpenAI

OpenAI has the most aggressive FDE hiring in the industry, with roles across multiple continents and specializations:

• Forward Deployed Engineer - NYC

• Forward Deployed Engineer - Dublin

• Forward Deployed Engineer - Gov (San Francisco)

• Forward Deployed Engineer - GPS (Sacramento, CA)

• Platform Engineer, Forward Deployed Engineering (FDE) - SF

• Design Verification, Forward Deployed Engineering (multiple locations)

• Estimated open roles: 15-20+ positions across multiple geographic hubs

Anthropic

Anthropic’s Applied AI team is growing aggressively to compete with OpenAI:

• Applied AI Engineer (London, UK)

• Applied AI Engineer, Beneficial Deployments

• Multiple Applied AI roles across regions

• Estimated open roles: 10-15+ positions

• Strategic context: Anthropic’s Applied AI team is scaling to support enterprise deployments of Claude

Palantir Technologies

As the FDE pioneer, Palantir maintains the largest dedicated FDE hiring pipeline:

• Forward Deployed Software Engineer (multiple locations)

• Forward Deployed Infrastructure Engineer - UK Government (London)

• Forward Deployed Software Engineer - various regions

• Estimated open roles: 20-30+ positions

• Salary range: $135,000-$200,000 base (from published job postings)

Scale AI

Scale AI is building out its Applied AI engineering team to support enterprise customers:

• Applied AI Engineer roles

• Customer-focused deployment positions

Microsoft, Google, Meta

These companies are building AI deployment capabilities but have not yet formalized “FDE” as a distinct role title. Meta recently announced plans to launch an Enterprise Solutions unit with embedded engineers (May 2026), signaling that the FDE model is becoming table stakes across the industry [3].

The Trillion-Dollar Opportunity: Automating the FDE Function

The FDE role is currently the bridge from the technical market to the non-technical market. But the long-term play is automation.

Every major coding agent and LLM company will eventually attempt to productize their FDE teams. We are already seeing the beginnings of this. Voice agents are running discovery interviews to map workflows. Cloud agents are building prototypes. Sub-agents are prioritizing AI use cases based on business impact versus engineering effort.

Context extraction and creation is the next most valuable problem to solve. If you can figure out how to extract and create context at scale, the financial upside is massive. The coding agents can handle the rest.

Until that automation is perfected, the Forward Deployed Engineer remains the most critical, and highest-paid, human in the enterprise AI deployment loop.

If you would like to read interesting articles like these check out my previous articles

References

[1] Mike Fishbein on X. “After 40+ forward deployed engineering (FDE) engagements...”

[2] FDE Academy. “How Palantir Invented the Forward Deployed Engineer Model” https://fde.academy/blog/how-palantir-invented-the-forward-deployed-engineer-model

[3] Forbes. “AI Giants Bet Billions On The Most Expensive Job In Enterprise” https://www.forbes.com/sites/janakirammsv/2026/05/28/ai-giants-bet-billions-on-the-most-expensive-job-in-enterprise/

[4] Hashnode. “The complete 2026 guide to the forward deployed engineer” https://hashnode.com/blog/a-complete-2026-guide-to-the-forward-deployed-engineer

[5] OpenAI. “OpenAI launches the OpenAI Deployment Company to help businesses build around intelligence” https://openai.com/index/openai-launches-the-deployment-company/

[6] Glassdoor. “Forward Deployed Engineer Salaries” https://www.glassdoor.com/Salaries/forward-deployed-engineer-salary-SRCH_KO0,25.htm

[7] Recruiting from Scratch. “Forward Deployed Engineer Salary in 2026: Real Data from 200K Job Postings” https://www.recruitingfromscratch.com/blog/forward-deployed-engineer-salary-in-2026-real-data-from-200k-job-postings

[8] Perspective AI. “The 2026 Forward Deployed Engineering Compensation Report: What 1,200 FDEs Earn” https://getperspective.ai/blog/2026-forward-deployed-engineering-compensation-report-1200-fdes

Earlier, building and setting up AI agents was complex. You had to understand libraries like LangChain, set up custom Docker containers, and manage sessions, knowledge evals, and a lot of other moving parts. It was an infrastructure nightmare.

Anthropic has since launched Managed Agents, which makes building and deploying agents much simpler than before. Within 30 minutes, I built an autonomous agent that queries my Supabase database, recommends tools, and runs in its own secure sandbox. The infrastructure management completely vanished.

If you’re still building custom harnesses for your AI agents or trying to make chatbots do agentic work, this tutorial is for you. I’m going to walk you through exactly how I built “The Tool Nerd Advisor” from scratch using Claude Managed Agents.

Check out my previous articles:

Subscribe now

AI Agent vs Chatbot: Understanding the Difference

Every time someone says “I built an AI agent,” they usually mean they built a chatbot with a fancy system prompt. That distinction matters a lot.

A chatbot responds to your message and forgets everything the moment the conversation ends. It has no tools, no memory, and no ability to work independently. You have to drive every single step.

A claude-managed agent works differently at a structural level. It runs in a hosted environment, calls real APIs, executes code, and maintains state across multiple sessions. You can start a task, close your laptop, and the agent keeps working. When you come back, the full execution history is waiting for you.

Anthropic’s platform makes this possible by splitting the AI agent architecture into three separate concerns:

The Brain is the Claude model plus the harness - the system prompt, decision logic, and tool routing.

The Hands are the execution environment - a secure cloud sandbox where the agent runs code and calls APIs.

The Session is the persistent event log - an append-only record of everything that happened, which survives container restarts and context window limits.

This separation is what makes long-running AI agents possible. The container can crash, the context window can fill, and the session state still lives. You just spin up a fresh container and pick up exactly where you left off.

When to Deploy AI Agents in the Cloud

The question I get most often is: “When should I use a managed agent instead of just calling the LLM API directly?”

The answer comes down to three things: task duration, tool complexity, and credential security.

If your use case involves calling real APIs, running for more than a few seconds, or handling sensitive credentials, deploying an AI agent is the right approach. If you just need a Q&A interface, a regular API call works fine.

What I Built: The Tool Nerd AI Advisor

Integrating Supabase as the Retrieval Layer

My goal was an agent that could act as a technical advisor for TheToolNerd.com. It needed to query my AI tools database on Supabase, recommend tools based on user budget and workflow, compare features, summarize blog articles, and do all of this without ever exposing my Supabase API keys to the execution environment.

Here is the exact prompt I used:Build an AI-powered recommendation and discovery agent for The Tool Nerd ecosystem.

The agent should recommend the right AI tools from my database at tools.thetoolnerd.com based on the user’s goals, workflow, budget, technical expertise, and preferences.

The agent should also act as a conversational assistant for my blog thetoolnerd.com by answering questions, summarizing articles, comparing tools, and helping users discover relevant content.

Core Capabilities:
1. Tool Recommendations
- Recommend the best tools based on user intent
- Ask follow-up questions when needed
- Compare tools with pros, cons, pricing, and ideal use cases
- Support categories like AI coding, design, automation, productivity, agents, video, writing, research, and CRM
- Personalize recommendations for beginners, creators, developers, founders, marketers, and enterprises

2. Knowledge Assistant
- Answer questions using content from thetoolnerd.com
- Summarize blog posts in simple language
- Explain AI concepts and workflows
- Recommend related articles and tools naturally during conversations

3. Data & Research
- Use Supabase as the primary database and retrieval layer
- Use tools.thetoolnerd.com as the structured tools database
- Use thetoolnerd.com articles as the knowledge base
- If information is missing, perform web research to find and validate relevant tools or supporting information
- Always prioritize and return URLs from my Supabase database whenever available

4. Conversational Style
- Friendly, practical, and non-hype tone
- Give honest recommendations instead of promotional responses
- Keep answers concise first, with optional deep dives

5. Outputs
The agent should generate:
- Tool recommendations
- Comparison tables
- “Best tool for X” answers
- Workflow suggestions
- AI stack recommendations
- Beginner learning paths
- Blog summaries and related content suggestions

The experience should feel like talking to an AI-native tech advisor who deeply understands modern AI tools and workflows, not just a search engine.

Step-by-Step Tutorial: Creating Your Managed Agent via Claude Console

Step 0: Navigating the Claude Console Dashboard

When you first open the Claude Console, you land on the dashboard. This is where you manage your entire AI agent infrastructure - agents, sessions, environments, and credential vaults.

The left sidebar shows the full structure:

Build (for workbench and files),

Managed Agents (agents, sessions, environments, vaults, memory stores), and Analytics.

The dashboard shows your credit balance, monthly spend, and token volume at a glance.

Notice the “Managed Agents” section in the sidebar - this is where everything lives. Before I started, I had one existing agent (a Wealth Planning Agent I’d built earlier). The credential vaults section was empty.

Step 1: Define Your AI Agent Configuration and Persona

Click “Quickstart” in the sidebar. The platform gives you two options: describe your agent from scratch, or start from a pre-built template.

The templates cover common enterprise AI agent use cases - Deep Researcher, Support Agent, Data Analyst, Incident Commander. For my case, I described the agent from scratch. I pasted my full prompt into the chat window and hit send.

What happened next surprised me. The platform didn’t just take my prompt and create an agent. It started a conversation - asking clarifying questions about the persona, the honesty rules, and the output format I wanted.

Step 2: Auto-Generating and Refining the YAML Agent Config

As I answered the platform’s questions, the YAML configuration built itself on the right side of the screen.

The config shows the full agent definition: name, description, model, system prompt, and tool configuration. I could see it was using claude-sonnet-4-6 by default and had already added the Supabase MCP server to the tools list.

I noticed the model choice and asked the platform to switch to claude-haiku-4-5 - faster and cheaper for a recommendation use case that doesn’t need deep reasoning.

The platform updated the YAML immediately. It also added the persona I’d described: “You are Nerdy - the friendly, enthusiastic AI advisor for thetoolnerd.com.”

And it added the honesty rule I care about most: if you don’t know something, say “I don’t know” - never make up tool names, pricing, or URLs.

Once the config looked right, I clicked “Create this agent.”

The platform showed a confirmation with the exact cURL command used to create the agent via the API. This is a pattern throughout the platform - every action shows you the underlying API call. When you’re ready to move from console to code, you already have the commands.

Step 3: Setting Up the Isolated Sandbox Execution Environment

An agent needs somewhere to run. In the DIY world, this means provisioning a container, configuring networking, and managing secrets. Here, it’s a few clicks.

I created a new environment called tool-nerd-advisor-env. The key setting here is networking - I set it to “Unrestricted” so the agent could reach Supabase and do web searches when needed. The platform provisioned the sandbox immediately.

Each environment is isolated. If you’re building multiple agents, they each get their own sandbox. No shared state, no interference.

Step 4: Securing API Credentials with the Credential Vault and MCP Proxy

This is the part that took me longest to understand when I first started building AI agents, and it’s the part most developers also face challenge.

My agent needs to query Supabase. That requires an API key. The naive approach is to put the key in the system prompt or in an environment variable. Both approaches are dangerous - a prompt injection attack could extract the key, and environment variables in the sandbox are accessible to any code the agent runs.

The Credential Vault solves this properly.

The vault stores credentials separately from the execution environment. When the agent needs to call Supabase, it goes through an MCP (Model Context Protocol) proxy that injects the credentials at the network layer. The agent never sees the API key. It just makes requests, and the proxy handles authentication.

There’s an important warning the platform shows here: vaults are shared across your workspace. Anyone with API key access to your workspace can use credentials in the vault. For a solo project, that’s fine. For a team, you’ll want to think about access controls.

I clicked “Create a new vault” and named it “Tool Nerd Vault.”

The Supabase OAuth flow popped up. It listed exactly what permissions Claude was requesting: read analytics, read/write Postgres configs, read/write edge functions, read API keys, read storage buckets. I reviewed the list, confirmed it matched what I needed, and authorized.

“Supabase credential added to vault. Nerdy is ready to go.” The platform confirmed the connection and gave me two options: Test Run or Keep Refining. I hit Test Run.

Step 5: Live Testing and Real-Time Event Stream Debugging

The Preview tab opened with a live session connected to tool-nerd-advisor-env. I typed my first test query:

“I’m a marketer with no coding experience and a budget of $50/month. What AI tools should I be using?”

The Debug tab showed the agent’s execution in real time. First, it called List Projects to connect to Supabase and verify the connection. Then it wrote a SQL query to find marketing tools within the budget constraint.

Then it hit an error.

The SQL query assumed a column called free_tier existed in my tools table. It doesn’t. The query failed with a schema error. But watch what happened next: the agent didn’t crash or return a generic error message. It called List Tables to inspect the actual schema, rewrote the query using the columns that actually existed, and successfully retrieved the data.

The final response was a formatted marketing stack recommendation with AISEO at $15/month and HyperWrite at $16/month - both within budget, both pulled from my actual Supabase database.

The whole run took 1 minute 10 seconds and used 110k input tokens with 1.8k output tokens.

Overcoming Schema Errors: The Agentic Debugging Loop

Leveraging Post-Session Analysis for Automated Prompt Fixes

After the session closed, the platform ran a post-session analysis. This is the feature that separates Anthropic Managed Agents from every other agent framework I’ve used.

The analysis read:

“The run went well overall - Nerdy connected to Supabase, listed tables, and ran multiple SQL queries to pull tool recommendations. There was one minor schema error: Nerdy assumed a free_tier column that doesn’t exist in your database. It recovered gracefully and continued, but this will be a recurring hiccup unless we fix it.”

Then it offered a choice: “Update the system prompt to not assume column names” or “Rerun as-is.”

I selected the fix. The platform automatically updated the system prompt with a rule: always inspect the schema before writing SQL, never assume column names.

I ran the agent again. Version 2 hit a different error - this time a Postgres array syntax issue. The agent used IN (...) on a column stored as a Postgres array type, which requires = ANY(...) syntax instead.

Same process: the platform caught it, explained the root cause, and suggested adding a SQL rule for array columns. I applied the fix. Version 3 ran without errors.

Three runs. Three versions. Each one more reliable than the last. The platform guided me through every fix without me having to read Postgres documentation or debug SQL manually.

Production Deployment: Integrating the Agent via Python SDK

Once the agent was working reliably in the console, the platform showed me the Python code to integrate it into my own application.

from anthropic import Anthropic
client = Anthropic()
session = client.beta.sessions.create(
    agent={"type": "agent", "id": "agent_xxxxxxxxxx"},
    environment_id="env_xxxxxxxx"
)
with client.beta.sessions.events.stream(
    session_id=session.id,
) as stream:
    client.beta.sessions.events.send(
        session_id=session.id,
        ...
    )

Pass the Agent ID and Environment ID, stream the events, and you have a production-ready autonomous worker running in your application. The “Scaffold in Claude Code” button generates a full project structure if you want to go further.

DIY AI Agent Frameworks vs. Claude Managed Agents: An Honest Assessment

I’ve built agents on LangChain, CrewAI, and custom Python harnesses. Anthropic’s Managed Agents platform is the first one where I found it easy to build compared to others.

The Standout Features: Persistent State and Error Recovery

The debugging loop is the standout feature. Most platforms show you that something failed. This platform tells you why it failed, what the fix is, and applies it for you. That alone cut my iteration time by more than half.

The Trade-offs: Ecosystem Lock-In and Token Cost

The tradeoffs are real though. You’re locked into Anthropic’s orchestration layer, which means Claude models only. The platform is in beta, so some rough edges exist. And the pricing model - credits per token - can add up quickly for agents that run long sessions.

If you’re building workflows that need long-running execution, real API integrations, or secure credential management, this is the right platform. If you’re building a simple Q&A interface, a direct API call is still the better choice.

Next Steps for Building Complex Autonomous Workflows

If you want to go deeper on AI agent deployment and architecture before building your own, these articles from my earlier blogs cover the foundations:

• AI Roadmap for Beginners - 4 Part series on AI Roadmap.

• How I Use OpenClaw to Run a 7-Agent Mission Control System - a real-world multi-agent setup

• The Great AI Hypocrisy: Why “Anyone Can Build Anything” Companies Buy Their Software - context on why managed infrastructure matters

The platform is at platform.claude.com. The Managed Agents section is under the left sidebar. The Quickstart wizard takes about 5 minutes to get through.

Build your first agent.

We often talk about hiring “rockstars” and “10x engineers,” but what happens when those exceptional individuals join our organisations? Do we give them the environment they need to truly lead, or do we inadvertently clip their wings?

This question became vividly clear to me during a recent trip to the Tadoba Tiger Reserve, one of the densest tiger reserves in the world. While observing these magnificent creatures in their natural habitat, I uncovered profound leadership lessons that directly apply to building and managing high-performing tech teams and AI solutions.

The Uncaged Leader: Why High-Performing Talent Needs Autonomy

Imagine a tiger. It hunts, eats, and sleeps entirely on its own terms. It carves out its territory, sets its own rules, and operates with an inherent sense of independence. A tiger is the ultimate natural leader—unbeholden, self-sufficient, and powerful because it’s free to be itself.

In the corporate world, especially in fast-paced tech and AI development, everyone wants to hire leaders. We search relentlessly for individuals with that rare blend of independence, decisiveness, and innate drive. We want people who can take ownership, innovate, and push boundaries. Essentially, we want tigers.

If you love this, checkout my previous articles here.

Subscribe now

But here’s the paradox: once we bring these “tigers” into our organizations, we often try to put them in a cage. We impose rigid processes, layers of bureaucracy, and micro-management. We expect them to operate within predefined boxes, follow every instruction, and conform to a system that stifles their natural instincts. We want the power of a tiger, but we want it safely contained.

This approach is fundamentally flawed. Natural skills—especially those of a true leader or an innovative engineer—only emerge and flourish in a natural, empowering environment. If you hire a tiger and then restrict its movement, you’re not going to get a tiger; you’re going to get a frustrated, underperforming house cat.

Great leaders, like tigers, aren’t servants to a system; they are the system, creating their own impact and driving progress.

The Thrill of Uncertainty: Embracing Risk in AI & Innovation

My safari experience also highlighted a crucial aspect of human nature and its impact on innovation: our obsession with certainty.

When you go on a safari, the probability of finding a tiger is never 100%. You might drive for hours, see nothing, and feel the disappointment build. But that very uncertainty is what makes the eventual sighting so thrilling, so memorable. It’s an earned experience, a moment of pure, unadulterated awe.

Compare this to a zoo. You’re 100% certain to see a tiger. Yet, the experience, while educational, lacks the same visceral excitement. The certainty kills the magic. We, as humans, crave certainty in our projects, our product roadmaps, and our careers. We try to eliminate all risks, predict every outcome, and guarantee success.

However, true innovation, especially in AI, thrives on uncertainty. The most groundbreaking discoveries often come from exploring the unknown, taking calculated risks, and embracing the possibility of failure. When we over-optimize for certainty, we strip away the elements of surprise and discovery that fuel creativity and lead to truly memorable breakthroughs.

Building an AI product is not about following a perfectly predictable path; it’s about navigating a complex, often uncertain, landscape and finding new ways forward.

The Value of Scarcity: A Patient Approach to Hiring Exceptional Leaders

Finally, the safari reinforced the principle of scarcity. You need immense patience to find a tiger in the wild because they are rare. Their scarcity is precisely what makes them so valuable and sought after.

If tigers were abundant, if they were behind every bush, the thrill and effort of seeking them out wouldn’t be the same.

This applies directly to talent acquisition and fostering innovation in tech. People with genuine leadership qualities, unique technical talents, or a truly innovative mindset are scarce. They are not easily found, nor can they be mass-produced. Identifying and attracting these individuals requires patience, a keen eye, and a willingness to invest time and effort in the search.

Just as you wouldn't expect to stumble upon a tiger without effort, you shouldn't expect to build a team of exceptional leaders and innovators without a deliberate, patient, and discerning approach.

And once you find them, the lesson from the uncaged tiger becomes even more critical: give them the freedom and environment to flourish, or their rare value will be diminished.

Key Takeaways for Tech Leaders:

• Empower Autonomy: Hire leaders and innovators, then give them the space and freedom to operate. Avoid the “tiger in a cage” mentality.

• Embrace Uncertainty: Recognize that true innovation and memorable achievements often arise from navigating unpredictable paths, not from rigid, risk-averse planning.

• Value Scarcity with Patience: Invest time and effort in finding rare talent. Once found, nurture their unique abilities by providing an environment where they can thrive naturally.

My Tadoba experience was more than just a wildlife sighting; it was a powerful reminder that the principles governing the wild often hold profound truths for the boardrooms and development sprints of the tech world. Let’s build teams where our tigers can roam free and lead us to uncharted territories.

Think of AI Agent Skills as the “apps” for your AI agent. They are reusable, procedural best practices that you can inject directly into your agent’s brain. Instead of prompting your AI to “be a good developer,” you install a Skill that forces it to follow a specific, battle-tested workflow.

Whether you are using Claude Code, Cursor, Codex, or Windsurf, these AI agent skills ensure that your agent doesn’t just work - it works correctly. In this guide, I’m breaking down the top 10 AI agent skills that have completely transformed how I build products, from initial brainstorming to shipping production code.

The Open Agent Skills Ecosystem: Skills.sh

Before we dive into the list, we need to talk about where you can find these skills. You can find a plethora of skills in skills.sh.

Built and maintained by the Vercel team, skills.sh is the open directory for agent capabilities. It currently hosts over 91,000 skills across various topics—from React best practices to security audits and marketing strategies. It supports a massive ecosystem of agents, meaning a skill built for Claude Code can often be utilized by Cursor or GitHub Copilot. It’s the ultimate repository for copying the mental models of the world’s best engineers and enhancing your AI workflow.

Reference: If you’re new to building your own AI agent skills, check out my previous guide on How to Build Claude Skills: Complete Guide + MCP.

Subscribe now

The Top 10 AI Agent Skills for Enhanced Productivity

I’ve curated this list based on my daily usage and the trending data from skills.sh.

1. Brainstorming (obra/superpowers)

Total Installs: 147.7K

Install Command: npx skills add obra/superpowers

This is where every project of mine starts. I use the brainstorming skill to define product requirements or validate a raw idea. It doesn’t just give you a list of ideas; it pressure-tests your assumptions using first principles. This skill is invaluable for cutting through the noise and getting to the core of a problem. It forces your agent to ask critical questions, challenge assumptions, and explore alternative solutions, ensuring that the foundation of any project is solid before a single line of code is written.

2. Skill Creator (anthropics/skills)

Total Installs: 196.1K

Install Command: npx skills add anthropics/skills

The meta-skill. If you want to build your own custom workflows, this is essential. It helps you define the schema, write the instructions, and even set up evaluations to make sure your skill actually works. This skill empowers you to transform your unique processes into reusable, shareable assets. It guides you through the entire lifecycle of skill development, complete with testing frameworks to ensure reliability. I wrote about the Skill Creator 2.0 update here.

3. Frontend Design (anthropics/skills)

Total Installs: 391.8K

Install Command: npx skills add anthropics/skills

This is the most popular skill on the market for a reason. It gives your agent the official Anthropic design guidelines, ensuring that any UI it generates is clean, accessible, and modern. No more “AI-looking” buttons. It translates abstract design principles into concrete, actionable instructions, allowing your agent to generate high-fidelity mockups and component libraries that adhere to established design systems.

4. Caveman (juliusbrussee/caveman)

Total Installs: 124.4K

Install Command: npx skills add juliusbrussee/caveman

Context is expensive. Caveman is my secret weapon for context improvement and saving tokens. It aggressively prunes unnecessary files and forces the agent to speak in terse, minimal-token English.

Here is a real “Before and After” from the repository:

• Normal Agent (69 tokens): “The reason your React component is re-rendering is likely because you’re creating a new object reference on each render cycle. When you pass an inline object as a prop, React’s shallow comparison sees it as a different object every time, which triggers a re-render. I’d recommend using useMemo to memoize the object.”

• Caveman Agent (19 tokens): “New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.”

It cuts token usage by up to 65% without losing technical substance.

5. Agent Browser (vercel-labs/agent-browser)

Total Installs: 257.0K

Install Command: npx skills add vercel-labs/agent-browser

Stop copying and pasting documentation. agent-browser allows your coding agent to actually “see” the web, navigate to docs, and extract the information it needs to solve a bug or implement a new API. It eliminates the need for manual information retrieval, allowing the agent to integrate external knowledge seamlessly into its problem-solving process.

6. Hyperframes (heygen-com/hyperframes)

Total Installs: 36.1K

Install Command: npx skills add heygen-com/hyperframes

Want to show off your product? I use Hyperframes to create high-quality videos of my product ideas directly from the terminal. It’s a game-changer for building “demo-first” products. By simply describing your product’s features, Hyperframes can produce professional-grade video content, accelerating the feedback loop during product development.

What you can build:

• Animated Social Overlays: Create Instagram “Follow” cards or X post cards with smooth entry animations.

• Dynamic UI Showcases: Render 3D iPhone and MacBook showcases for your web apps.

• VFX Text Cursors: Add cinematic flair to your product landing pages with just a few lines of HTML/CSS.

> Watch it in action: Demo of HeyGen’s HyperFrame | Claude + HeyGen: Automated Videos Tutorial

Check out https://www.hyperframes.dev/ for some inspiration

7. Remotion Best Practices (remotion-dev/skills)

Total Installs: 299.9K

Install Command: npx skills add remotion-dev/skills

If you’re building video-based products, you need this. It injects the best practices for Remotion (React-based video) into your agent, making it trivial to programmatically generate complex animations. It streamlines the creation of dynamic video content by leveraging the agent’s ability to understand and apply complex programming paradigms.

Community Favorites:

• Travel Route on Map: A stunning 3D map animation with landmarks, perfect for travel apps.

• Three.js Ranking Videos: Data-driven “Top 20” ranking videos with cinematic transitions.

• Product Launch Teasers: High-energy launch videos for X (Twitter) that look like they were made by a professional motion designer.

> Watch it in action: Remotion + Claude Skills: The Future of Video Creation | Generate Animated Videos with Claude Code

8. Marketing Skills (coreyhaines31/marketingskills)

Total Installs: 103.6K

Install Command: npx skills add coreyhaines31/marketingskills

Building the product is only half the battle. I use Corey Haines’ marketing skills for SEO audits and copywriting. It helps me ensure that what I build actually reaches the people who need it. This suite equips your agent with the knowledge to perform competitive analysis, generate compelling ad copy, and optimize content for search engines.

9. Grill-me (mattpocock/skills)

Total Installs: 110.3K

Install Command: npx skills add mattpocock/skills

Matt Pocock is a legend in the TypeScript world. His grill-me skill allows your agent to interrogate your codebase, finding architectural flaws and suggesting improvements that most developers would miss. It acts as an expert code reviewer, identifying subtle bugs and performance bottlenecks to ensure your codebase remains robust.

10. Context Mode (mksglu/context-mode)

Total Installs: 465+ (Trending)

Install Command: /plugin install context-mode@context-mode (Claude Code)

If you’re tired of your agent “forgetting” things halfway through a session, Context Mode is the ultimate fix. While other skills focus on what the agent does, Context Mode optimizes how it remembers. It uses a sandbox approach to keep raw tool data out of your context window, achieving a staggering 98% reduction in token usage.

The “Think in Code” Paradigm:

Instead of reading 50 files into context to analyze them (which would cost ~700 KB), Context Mode nudges the agent to write a script that performs the analysis and returns only the result (~3.6 KB). It’s the difference between a data processor and a code generator.

My “Superpower” Workflow: From Idea to Code

I don’t just use these skills in isolation. I chain them together into what I call my Superpower Workflow.

1. Brainstorm: Use brainstorming to validate the idea.

2. Spec: Use a custom skill to write the technical spec.

3. Plan: Use writing-plans to map out the implementation.

4. Build (TDD): I use a Test Driven Development (TDD) methodology. I have the agent write the tests first, watch them fail, and then write the code to make them pass.

> Deep Dive: I actually wrote a full breakdown of How Claude Built a TDD Skill if you want to see this in action.

The Verdict: Elevate Your AI Workflow with Agent Skills

AI Agent Skills are the bridge between “AI as a chatbot” and “AI as an engineer.” If you aren’t using them, you’re working twice as hard for half the result.

Looking for more tools? Check out my full directory at tools.thetoolnerd.com.

Can you actually evaluate talent through a resume?

Most hiring leaders would say “NO”. Yet, we’ve built an entire industry around it. Applicant Tracking Systems, resume screening tools, keyword matching algorithms- all designed to make resume evaluation faster, smarter, more objective.

But here’s what’s actually happening:

We’re not evaluating talent anymore. We’re evaluating presentation.

And now that AI has entered the picture, we’re not even evaluating presentation well. We’re evaluating how well a resume matches the stylistic patterns of the AI tool doing the evaluation.

The research now proves it:

When AI evaluators shortlist candidates, they favor their own writing style by up to 82%.

Vasumathi (Associate Director HR at Altir) and I have been discussing a shift in the hiring landscape where “presentation” has completely replaced “judgment” and how AI-based hiring systems might be stopping you from hiring the right candidate.

I have co-authored this article with her.

Now, to understand why this is happening, we have to look at how we got here.

Subscribe now

How Hiring Broke: The Shift to Automated ATS and AI Evaluators

Hiring didn’t suddenly become broken. It degraded gradually, with each new system optimising for something slightly different from the last.

The Headhunting Era

There was once a time when recruitment largely depended on headhunting. Recruiters and talent specialists actively approached skilled professionals. They built relationships. They assessed capabilities through conversations. Hiring decisions relied heavily on human judgment, industry understanding, and the ability to identify potential beyond a document.

The problem? It didn’t scale.

The Resume-Driven Era

With the rise of job portals, the hiring process became more resume-driven. Candidates invested significant time building their resumes. The quality of resume content became one of the primary filters for recruiters.

A single job posting started attracting hundreds, sometimes thousands, of resumes. Recruitment gradually became a race against time, attention span, and luck. Often, the resumes reviewed first had a greater chance of selection, and candidates who were better at presenting content had a stronger advantage regardless of actual capability.

Candidates who were better at presenting content had a stronger advantage regardless of actual capability.

The ATS Era

Then came Applicant Tracking Systems (ATS). They promised to solve the volume problem. But ATS had a limitation: It could only parse what was on the page. Candidates learned to optimise with keyword stuffing and formatting tricks. Presentation became even more important than substance.

The AI-Assisted Era

Today, hiring has entered another phase. Most Applicant Tracking Systems (ATS) now integrate AI-powered screening tools that promise to reduce recruiter effort by 50% or more.

However, this raises an important question

“Is AI truly solving the hiring problem, or simply accelerating an already flawed filtering process?”

We’ve actually seen this movie before. Back in 2018, Amazon famously had to scrap a secret AI recruiting tool because it was actively penalizing resumes containing the word "women's." The model had trained itself to favor male candidates based on 10 years of historical tech-industry resumes.

We assumed the AI got smarter since then. But today, candidates are no longer writing resumes independently. AI tools are now generating highly polished, optimised, and role-specific resumes within minutes. Even job portals now offer AI-assisted resume writing as a premium feature.

As a result, almost every candidate today appears “well-written” on paper, even when practical expertise may be limited.

This brings us to the uncomfortable research that proves what many HR leaders already suspected.

AI Hiring Bias Research: Why LLMs Prefer Their Own Resumes

Researchers at the University of Maryland, National University of Singapore, and Ohio State University conducted a large-scale resume correspondence experiment using 2,245 real resumes sourced from a professional resume-building platform - collected before widespread AI adoption.

For each resume, they generated multiple counterparts using seven different LLM models: GPT-4o, GPT-4o-mini, GPT-4-turbo, LLaMA 3.3-70B, Mistral-7B, Qwen 2.5-72B, and Deepseek-V3.

Then they tested whether these LLMs, when acting as evaluators, systematically favoured their own generated content.

The answer: Yes. Dramatically.

LLMs showed strong and consistent preference for resumes they generated over human-written equivalents.

Larger models like GPT-4o, GPT-4-turbo, DeepSeek-V3, Qwen-2.5-72B, and LLaMA 3.3-70B exhibited particularly strong bias, exceeding 65% even after controlling for content quality.

They then simulated realistic hiring pipelines across 24 different occupations.

The disadvantage was most severe in business-related fields: sales, accounting, and finance.

Evaluations focus less on a candidate’s actual skills and more on whether their style matches what the evaluator LLM expects.

The Real Problem with AI in Recruitment: Presentation vs. Capability

The real issue isn’t just that AI prefers its own outputs. The deeper issue is that we’re evaluating the wrong traits entirely.

"If AI is being used to create resumes and AI is also being used to evaluate them, can organizations truly rely on AI-generated evaluations as indicators of capability?"

Right now, most hiring systems measure what is easy to parse: resume polish, AI stylistic alignment, keyword density, and communication ability. But what actually predicts whether someone succeeds in a role is execution ability, judgment, adaptability, and ownership.

There is a massive gap between those two lists. Think about the disconnect:

• Resume quality doesn’t equal job capability. A beautiful resume doesn’t mean you can ship code, close deals, or manage a team under pressure.

• Communication polish doesn’t equal execution ability. Someone can sound brilliant on paper and freeze when they need to make a real decision.

• AI-optimized language doesn’t equal authentic expertise. You can use AI to make your resume sound like you have deep expertise in something you’ve never actually done.

We chose easy over accurate. And the consequence is predictable: candidates get shortlisted for presentation rather than capability.

"The candidates who succeed aren't always the ones with the best resumes. They're the ones with judgment, adaptability, and genuine ownership. Those qualities don't show up on a resume. They show up in how someone approaches a problem."

If this pattern continues, dominant AI styles will become entrenched in hiring pipelines. We already know from recent research that automated recruitment tools continue to enable systemic discrimination and demographic bias.

But now, we are layering an entirely new problem on top of it. We are decreasing diversity through stylistic bias. Applicant pools will start to look less like a diverse spectrum of human capability, and more like the generic outputs of whichever LLM is currently the most popular.

These are a few of the major reasons many organizations today experience a growing skill gap despite extensive hiring efforts. Candidates are often shortlisted based on communication ability, resume presentation, and AI-enhanced articulation. However, when actual business outcomes and execution responsibilities arise, organizations frequently discover gaps in technical depth, ownership, adaptability, and real-world capability.

So, how do we fix a system that’s optimising for the wrong things?

Subscribe now

Mitigating AI Hiring Bias: 3 Actionable Strategies for Recruiters

We can’t go back to pure human judgment. It doesn’t scale. We can’t rely on resumes alone. They don’t predict capability. A different approach is needed.

1. From Resume-Based to Task-Based Screening

Give candidates meaningful work to complete. Real work that reveals how they think.

Then evaluate how they approach the problem. See how they use tools. See how they navigate ambiguity. See how they ask questions when they don’t understand something.

This is harder to scale than resume screening. But it’s infinitely more predictive. I wrote about a similar concept in my previous article on the Token Test- a different take on hiring engineers. Give candidates real work, and you’ll see who they actually are.

2. From Presentation to Behavioural Evaluation

Stop optimising for resume polish. Start assessing alignment with company vision. Look for learning agility. Evaluate cultural contribution.

“The future of effective hiring may depend less on automated screening and more on strengthening recruiter judgment, hiring manager calibration, domain-based screening, and behavioral evaluation.”

Assess problem-solving orientation. Look for long-term capability, not short-term credentials. Evaluate authenticity and integrity. These don’t show up on a resume. They show up in how someone approaches a problem.

3. Mitigating AI Bias When You Do Use AI

If you’re going to use AI for screening, at least do it intelligently.

The research identified two simple interventions that work.

1. System prompting. Explicitly instruct the model to ignore the origin of the resume and focus only on substantive content. Tell it not to favour resumes that match its own style.

2. Ensemble voting. Don't rely on one giant model. Combine your primary evaluator (like GPT-4o) with smaller models that exhibit weaker self-recognition to dilute the bias.

These interventions reduce LLM-versus-human self-preference by 17% to 63% in relative terms. Not perfect. But substantial.

Closing

Hiring is one of the most consequential decisions an organization makes. Yet we’ve optimized it for efficiency at the expense of accuracy.

As hiring becomes more AI-assisted, the importance of human judgment becomes even more critical - not less.

AI can improve efficiency, but it cannot fully replace the human ability to identify potential, authenticity, integrity, and contextual fit. The challenge ahead for organizations is not merely managing AI bias- it is ensuring that hiring systems do not lose the ability to recognize real talent beneath AI-generated perfection.

Use AI for what it’s good at. Use humans for what they’re good at. And maybe, just maybe, you’ll actually hire the right people.

Co-authored with Vasumathi Adwant, Associate Director HR at Altir.

Explore AI tools for hiring and team building at tools.thetoolnerd.com

Related reading: The Token Test: How the Best Companies Will Hire Engineers from Now On

Source: Xu, J., Li, G., & Jiang, J.Y. (2026). AI Self-preferencing in Algorithmic Hiring: Empirical Evidence and Insights. arXiv:2509.00462v3.

But I have a counter argument against that trend. It’s not something everyone can afford and I think that’s not what a good engineer will be evaluated on.

The landscape of software engineering is shifting. As AI models like Claude, ChatGPT, Gemini and Opensource models like Kimi, GLM, Qwen etc.. become commoditized, the act of writing code is no longer the primary differentiator of a “good” engineer. When everyone has access to the same world-class coding intelligence, the focus shifts from the how to the what, the why, and—most importantly—the cost.

We are entering an era of “Economic Engineering,” where the elite developers will be those who can navigate a world of token budgets, proprietary agent skills, and complex architectural judgment. But here’s the catch: while large companies can afford to waste tokens on leaderboard games, most organizations cannot. The real competitive edge belongs to engineers who understand token efficiency as a first-class concern—not as a vanity metric, but as a core measure of engineering excellence.

1. The Rise of Token Economics: Why "Tokenmaxxing" is a Wrong Metric

The future of hiring is straightforward:

The total cost of an engineer will no longer be limited to their salary. Instead, it will encompass their “token footprint.” A developer who builds a feature at a fraction of the token cost of another is inherently more valuable in a world where running AI infrastructure is a major operational expense.

Your overall cost of hiring isn’t just about the CTC—it’s also about how efficiently they use tokens. Because the same features built by someone else might cost significantly more or less to generate.

This shift is already happening in real companies but in a wrong way.

At Meta, an engineer created an internal “token leaderboard” that ranks employees by token usage, awarding titles like “Token Legend” and “Session Immortal” to top users.

If you would like to keep updated with interesting insights like these do subscribe

Subscribe now

The problem? It’s created perverse incentives.

Engineers are burning tokens on throwaway projects, running wasteful agents, and asking AI to answer questions that documentation already covers—all to climb the leaderboard.

In 30 days alone, Meta employees burned through 60.2 trillion tokens, which at standard API pricing would cost approximately $900 million. Microsoft and Salesforce have similar leaderboards, with some engineers admitting they’re “tokenmaxxing” not because it produces better work, but because they fear being seen as insufficiently “AI-native.” Gergely Orosz documented this in detail in The Pulse: Tokenmaxxing as a Weird New Trend — it’s worth reading as a cautionary tale of what happens when companies measure the wrong thing.

This is the warning. The Token Test is the antidote.

This aligns with the shift I discussed in The Judgment Premium, where the value moves from intelligence (writing code) to judgment (optimizing outcomes). But now there’s a quantifiable metric: tokens spent per unit of business value delivered.

2. Beyond Syntax: Hiring for Architectural Judgment in the AI Era

For decades, technical interviews focused on whether a candidate knew the nuances of Java loops or TypeScript types. In the post-coding era, these are commodities. The new core competency is high-level judgment.

Hiring will never be the same again. You’re not just evaluating technical skills of writing code—you’re judging skills like architectural decisions, system design, and data modeling. That’s the core area of the builder, not whether you know loops in Java or C++.

This shift prioritizes what we call the “First Pass Rate” (FPR).

We can build a system where you evaluate people on the ‘first pass rate’—if they get the code exactly as per requirements, meeting all edge cases, in the first generation without any redoing.

Success will be measured by the ability to visualize a system so clearly that the AI can execute it perfectly on the first attempt, eliminating the expensive “redo” cycles that plague modern development.

But here’s what makes this possible: context engineering. As I’ve explored in What is Context Engineering? (And Why It’s Better Than Prompt Engineering), the industry is shifting toward the discipline of building the entire information environment that an AI system needs to succeed. When an AI system fails in production, it’s rarely because the prompt needed better wording. It’s because the model didn’t see the right information, saw too much irrelevant information, or couldn’t carry the right state forward.

This is where the hiring criteria change. Companies will now evaluate engineers on nine core skills:

These nine skills are the practical implementation of context engineering. They’re what separates engineers who waste tokens from engineers who optimize them. And crucially, they’re what separates engineers who can work with AI systems from engineers who can architect them.

3. BYOM: Why the Future of Engineering is "Bring Your Own Model"

We will be moving from “Bring Your Own Device” to “Bring Your Own Model” (BYOM).

Engineers will no longer arrive at a company with just a laptop; they will arrive with a proprietary “digital brain” of fine-tuned skills.

We’re moving into an era of Bring Your Own Model. Every person will bring their own coding models—filtered versions of big models or smaller models they’ve built themselves to run in the company premises. This isn’t just about the model itself, but the accumulated “agent skills” a developer has refined over their career. Every AI developer will have their own ‘agent skills’ which they have fine-tuned over years or months. These are proprietary skills they can carry into any company they work with.

This is the next evolution of the Anthropic Skill Creator workflow—where your value is the library of specialized skills you’ve built and benchmarked. But more importantly, it’s where model orchestration becomes a competitive advantage.

An engineer who knows how to combine Claude for complex reasoning, GPT for speed, and open-source models for cost efficiency will always outperform an engineer who relies on a single model. They’ll deliver better results at a fraction of the token cost.

4. The New Engineering Skills: Reading AI Code and Context Management

As AI generates mountains of documentation and code, the human role becomes one of the “Ultimate Editor.” This requires two overlooked skills: high-stamina reading and context switching.

One critical skill that will become increasingly important is reading skill. AI generates mountains of English. You need the patience to read it through, visualize, and understand it before handing it over to the coding agent. You cannot always rely on AI to read for you.

Furthermore, the complexity of managing a fleet of autonomous agents requires a unique cognitive ability to maintain state across multiple workstreams. Context switching is the toughest part for a human. Imagine working with multiple agents—you need to keep track of which agent is doing what, and whether the context is being managed properly. This is harder than it sounds.

Managing this complexity is why reading skill and context management are now hiring criteria. An engineer who can read through AI-generated documentation, spot the signal in the noise, and maintain coherent state across multiple agents is worth significantly more than an engineer who can’t.

5. The T-Shaped Business Engineer: Bridging AI Code and Business Metrics

The most successful developers will be those who refuse to stay in a technical silo. To provide an LLM with the right context, an engineer must understand the business objective of the code they are requesting.

You need to have a taste for everything. You should be able to say what is a good design—you don’t need to be the expert, but you should understand it. Most developers don’t understand the business; they just write code. If you have to be relevant, you need to understand which metric the feature you are building is going to move.

T-shaped engineer: deep technical capability combined with broad business acumen.

By understanding the product metrics—the “why” behind the feature—the engineer can architect solutions that don’t just work, but actually drive company growth and user satisfaction. This is the T-shaped engineer: deep technical capability combined with broad business acumen. They understand that token efficiency isn’t just about cost—it’s about delivering business value faster and cheaper.

Conclusion

The era of the “coder” is ending; the era of the “AI Architect” has begun. In this new world, your value isn’t found in the lines of code you write, but in the precision of your judgment, the efficiency of your tokens, and your ability to steer complex systems toward business reality.

While companies like Meta are building leaderboards that reward token waste, the best organizations are building hiring processes that reward token efficiency. They’re measuring context engineering skill, not raw consumption. They’re looking for engineers who understand that in an era where intelligence is commoditized, the real edge is efficiency—the ability to deliver more value with fewer resources.

The Token Test is how they’ll find them.

References & Related Reading

This article builds on several key industry trends and insights:

• Tokenmaxxing Trend: Gergely Orosz, The Pulse: Tokenmaxxing as a Weird New Trend (Pragmatic Engineer, April 2026) — documents how Meta, Microsoft, and Salesforce are creating token leaderboards and the perverse incentives they create. The cautionary data point: Meta burned 60.2 trillion tokens in 30 days, worth ~$900M at API prices.

• Context Engineering Shift: What is Context Engineering? (And Why It’s Better Than Prompt Engineering) — My deep dive into why the industry is moving from prompt engineering to context engineering, and how to build the entire information environment for AI systems. The nine skills in this article are the practical implementation of that framework.

• The Judgment Premium: My previous article on how the next $1T company will be built on judgment, not just intelligence—which directly connects to why token efficiency matters more than raw capability. -

• Anthropic Skill Creator: The evolution of how developers build and carry proprietary skills across companies, which ties directly to the BYOM (Bring Your Own Model) era. https://www.thetoolnerd.com/p/anthropic-skill-creator-20-update

• The Token Test isn’t just a hiring framework. It’s a recognition that in a world where AI capabilities are increasingly commoditized, the real differentiator is how efficiently you use them. That’s the future of engineering.

“You don’t need to buy software anymore. Just build it yourself.”

If you spend any time on X or LinkedIn, you’ve seen this pitch. The founders of the hottest AI companies are telling us that coding is dead, natural language is the new programming, and anyone can build a custom CRM or support system over the weekend.

It’s a compelling narrative. It’s also completely contradicted by their own actions.

I analyzed the internal tech stacks of the biggest names in AI—OpenAI, Anthropic, Replit, Lovable, and Bolt.new—using BuiltWith data. What I found is a massive gap between what they sell and what they do. These com

panies, armed with the smartest engineers on the planet and the most advanced AI models ever created, are not building their own internal tools.

They are buying them. Just like everyone else.

Here is the data-backed truth about the “build anything” myth, and the pragmatic lessons every founder needs to learn from it.

Check out my previous articles :

Subscribe now

The Data: What AI Companies Actually Use

When you look under the hood of these AI juggernauts, you don’t find custom-built, AI-generated internal tools. You find standard SaaS subscriptions.

About the data: BuiltWith is a Sydney-based web intelligence platform founded in 2007 that crawls millions of websites to detect the technologies they run — used by sales teams, analysts, and researchers worldwide as a standard source for tech stack data. It does quarterly crawls across its database, making it a reliable but point-in-time snapshot rather than a live feed.

Let’s break this down by category to see exactly where these companies choose to spend their money instead of their engineering time.

1. Customer Support: The Intercom Dominance

If there’s one area where you’d expect AI companies to build their own solutions, it’s customer support. After all, answering questions is what LLMs do best. Yet, the data shows a complete reliance on established vendors.

Anthropic didn’t build a custom support bot from scratch. They bought Intercom’s service and implemented FinAI

In a recent case study by FinAI, Emily Lampert, Head of Product Support at Anthropic, noted that Fin automatically resolved tens of thousands of customer queries, achieving a 50.8% resolution rate in just over a month [1].

Why didn’t Anthropic build this themselves? This is what their Product Support Operations said

They chose speed, trust, and Intercom’s deep expertise in customer service workflows over the vanity of building it in-house.

Make a note of this — “Deep Expertise in Customer Service”

Check out the case study

2. Project Management: The Linear Standard

Managing complex engineering projects requires robust tools. You might think companies building the future of software would create their own issue trackers. They don’t.

OpenAI uses Linear. They scaled it from a small trial to over 3,000 users across the organization [2]. Before Linear, cross-team collaboration at OpenAI was chaotic, with different teams using different tools.

Gabriel Peal, an engineer at OpenAI, explained the appeal:

They chose Linear because it remained fast and performant at scale, reducing the friction of creating and modifying tickets. They bought a tool that set a standard for quality craftsmanship, rather than wasting time building a mediocre internal clone.

Most of the Top AI companies you know are their customers - Cursor, Vercel, Perplexity, Lovable, Replit etc..

3. Documentation: The Mintlify Takeover

Developer documentation is critical for AI platforms. Surely, companies like Anthropic and OpenAI build their own custom documentation sites?

Wrong again.

Anthropic uses Mintlify to serve documentation to over 1.5 million developers every month [3]. When launching the Claude Sonnet 3.5 model, they needed a platform that could scale instantly without adding engineering overhead.

Instead of building infrastructure, Anthropic partnered with Mintlify to co-develop AI-native features like LLMs.txt, improving how their docs are ingested by other AI tools.

4. CRM and HR: The Enterprise Staples

The pattern continues across every major business function.

OpenAI, Anthropic, and Replit all use Salesforce. Bolt.new uses HubSpot. For hiring, they rely on Greenhouse and Rippling.

These are complex, heavily regulated, and feature-dense domains.

Building a CRM is easy. Maintaining a CRM that handles enterprise sales pipelines, integrates with marketing automation, and provides reliable forecasting is a nightmare.

The Pragmatism Behind the Hypocrisy

The irony is thick. The companies selling the dream of “code your own software” are making the exact opposite choice internally. But when you look past the marketing, their decisions make perfect business sense.

Here is why the smartest engineers in the world choose to buy:

1. Maintenance is the Killer
Building version 1.0 of a tool is easy, especially with AI. Maintaining it is brutal. Internal tools require constant updates, security patches, bug fixes, and feature additions. Every hour an engineer spends fixing an internal CRM is an hour they aren’t spending improving Claude or ChatGPT.

2. It’s Not Their Moat
Anthropic’s competitive advantage is their AI models, not their customer support software. Salesforce has 25 years of expertise in CRM workflows. Intercom has spent a decade perfecting customer communication. Why would an AI company try to rebuild that expertise from scratch?

3. Speed to Market
As the Anthropic/Mintlify case study shows, buying allows companies to move incredibly fast. You can deploy an enterprise-grade documentation site in days. Building it takes months.

The Build vs. Buy Framework for Founders

This data provides a wake-up call for founders and builders. Just because you can build it doesn’t mean you should.

Here is a pragmatic framework for making the Build vs. Buy decision:

When to BUILD:

• It is your core differentiator. If the software directly impacts your unique value proposition, build it. (e.g., OpenAI building their own model training infrastructure).

• Standard tools cannot handle your specific workflow. Your operations are so unique that modifying a SaaS tool would be harder than building from scratch.

• You need absolute control over data security. Regulatory or compliance reasons demand that the data never touches a third-party server.

When to BUY:

• It is a commodity function. CRM, HR, customer support, and project management are solved problems. Buy the solution.

• The vendor has deeper domain expertise. You cannot out-build Salesforce on CRM features or Intercom on support routing.

• You need to move fast. If time-to-market matters, buying is always faster than building.

• You want to avoid maintenance debt. Let the vendor worry about uptime, security patches, and feature requests.

The Verdict

The narrative that AI will replace all SaaS companies because “everyone will just build their own software” is a myth. The very companies creating this AI are proving it false every day.

They understand a fundamental truth of software engineering: the cost of software isn’t in the building; it’s in the maintaining.

Use AI to build your core product faster. Use AI to prototype new ideas. But when it comes to running your business, follow the lead of OpenAI and Anthropic. Buy the best tools available, and focus your engineering talent on the problems only you can solve.

References

[1] Intercom. “Anthropic Customer Story.” https://fin.ai/customers/anthropic
[2] Linear. “OpenAI Customer Story.” https://linear.app/customers/openai
[3] Mintlify. “Anthropic Customer Story.” https://www.mintlify.com/customers/anthropic