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

If you read this all the way through, you will end up with a working blueprint for a second brain that compounds over time. The goal is to replace scattered PDFs, browser tabs, notes, and chat threads with a system that keeps getting better as you add material.

That is what makes Andrej Karpathy’s llm-wiki gist worth studying. GitHub shows the gist was first published on April 4, 2026.1 The idea is simple and strong: instead of asking an LLM to rediscover your knowledge from raw files every time, you let it maintain a persistent wiki that keeps improving as new sources come in.1

This guide turns that pattern into a practical setup for TheToolNerd readers. The stack is straightforward.

Use Obsidian as the local knowledge base, use an agentic coding assistant such as Claude Code to maintain the wiki, and use a simple ingest workflow so every useful article, note, or transcript has a home.

If you already work with AI coding tools, this also fits well with my earlier write-ups on Claude Code and Windsurf. For adjacent tools, browse the TheToolNerd directory.

What you will get from this guide

Before you start building, it helps to know what this setup is supposed to give you.

Why this pattern matters

Most people still use LLMs like temporary search layers. They upload documents, ask a question, get an answer, and move on. That works for one-off retrieval, but it does not build memory. Karpathy’s argument is different. He describes a persistent, LLM-maintained wiki that sits between you and your raw documents, so synthesis happens once and then gets updated over time instead of being recomputed from scratch on every question.

“The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you’ve read.” - Andrej Karpathy

That is the real shift. You stop treating the model like a temporary answer machine and start using it as a maintainer for a knowledge system.

Check out my previous articles:

Subscribe now

The core idea in plain English

Keep your raw material raw, and let the model build the layer you actually read.

Your articles, notes, screenshots, transcripts, and PDFs live in a raw/ folder. Those files remain the source of truth. The model does not rewrite them. It reads them and updates a separate wiki made of Markdown pages. That wiki becomes the place where tools, concepts, companies, ideas, and cross-references live.

When you ask a question like “What AI editors have I covered?” the model no longer has to sift through untouched files every single time. It can check the wiki, read the index, follow the relevant pages, and answer from a body of knowledge that has already been organized.

The architecture without the fluff

Karpathy keeps the pattern intentionally abstract, but the practical version is easy to follow once you break it into layers.1

What matters most is the separation of responsibilities. raw/ is where source material lives. wiki/ is where the model writes pages. CLAUDE.md or AGENTS.md is where the operating rules live. index.md tells the model what pages already exist, and log.md tells it what happened recently.

Without that structure, you have a chatbot browsing a folder. With it, you have a repeatable maintenance workflow. How the system works

What makes the LLM Wiki pattern practical is that the operating model stays small. Karpathy reduces it to three operations: ingest, query, and lint.1 That is the right level of complexity for a first version.

Ingest means adding a new source to the raw collection and asking the model to process it. The model reads the source, updates existing pages, creates new ones where needed, refreshes the index, and appends an entry to the log.1

Query means asking questions against the wiki, not against a pile of disconnected files. This improves answer quality because the model is working from pages that already contain structure, cross-links, and synthesis.1

Lint means running a health check on the wiki. The model looks for stale claims, contradictions, missing links, orphan pages, and concepts that deserve their own page.1

Why index.md and log.md matter more than they look

These two files sound administrative, but they are the reason the system stays usable.

index.md is the content map. It tells the model what pages exist and what each one is about. Karpathy notes that this can work surprisingly well at moderate scale, which means you can postpone heavier retrieval infrastructure until you actually need it.1

log.md is the timeline. It records what was ingested, what was queried, and when maintenance passes happened. That gives both you and the model a clear sense of recency and change.1

Once a few sources are ingested, the Obsidian graph stops looking decorative and starts acting like a real map. You can see hubs, weak links, and isolated pages quickly.

Step 1: Create a local Obsidian vault

Start with a fresh vault in Obsidian. A literal name such as toolnerd-secondbrain works well because it is easy to reference in your terminal, your coding tool, and your Web Clipper settings.

Keep the vault local. That gives you ordinary folders and files underneath, which is exactly what you want when an agent is reading from raw/ and writing to wiki/.

Step 2: Open the same folder in your coding assistant

Open that vault folder in Claude Code, Cursor, Windsurf, or whichever agentic coding environment you prefer. Then give the agent the llm-wiki gist and ask it to instantiate the pattern inside that vault.

The point is to turn the abstract idea file into a working local structure.

Step 3: Let the agent scaffold the wiki

At this point, the agent should create the core folders and files for you. You want a clear raw-source layer, a wiki layer, a schema file, and the two support files that make the system navigable.

Do not overcomplicate this first version. A clean folder structure matters more than clever automation.

Step 4: Clip an article into raw/articles

Now move from setup to actual use.

Open an article you want to save, then use Obsidian Web Clipper to send it into the vault. In the clipper settings, make sure the vault name matches exactly. Set the destination folder to raw/articles so the article lands in the source layer instead of being mixed into the generated wiki.

• Add the Obsidian Web Clipper Extension

• Configure it if you want to store the pages in a specific vault

• Click Add to Obsidian

Step 5: Confirm the article landed in the vault

After clipping, the article should appear inside raw/articles as a Markdown file with metadata and body content. That file is now part of the raw layer. Leave it alone and let the model read from it.

Step 6: Run ingest on that file

Go back to your coding assistant and ask it to ingest the article. A simple command pattern works well here: put the file into raw/articles/ and run ingest [filename].

This is where the pattern starts to pay off. One source can update many pages. The model can revise tool pages, create concept pages, refresh summaries, and update the index in the same pass.

Step 7: Query the wiki, not the raw file

Once a few sources are ingested, shift your questions to the wiki layer.

Those questions work because they require synthesis, not simple retrieval. The wiki gives the model a place to reason from.

Step 8: Run lint when the wiki gets messy

Most people skip this part. That is a mistake.

Ask the model to lint the wiki for broken links, duplicated concepts, stale claims, missing pages, and weak cross-references. This is the maintenance loop that keeps the system usable after the novelty wears off.

Tips and tricks worth stealing from the original article

Karpathy’s gist includes several practical suggestions that are easy to miss on a quick read, and they are worth adopting early.1

Obsidian Web Clipper is the fastest way to convert a web article into clean Markdown. If you collect a lot of articles, it removes a lot of friction. Karpathy also suggests downloading images locally. That is more useful than it sounds. If an article includes diagrams, screenshots, or charts, local assets keep them accessible even after the original URLs break.

Graph view is useful because it shows whether your wiki is growing in clusters, whether some topics are becoming hubs, and whether you have orphan pages that need linking. Dataview is another good upgrade once your wiki pages have frontmatter. It can generate dynamic lists and filtered views from metadata, which is useful when you want better navigation across tool pages, concepts, or recent updates.

There is also a useful mental shift here: the wiki is the artifact, and the chat is only the interface. Once that clicks, you start saving useful answers back into the wiki instead of losing them in conversation history.

Where this setup is strong, and where it breaks

This pattern is strong when you are reading, collecting, and synthesizing over time. It works well for competitive analysis, article research, course notes, tool tracking, learning sprints, and personal knowledge management. It is especially good in domains where the links between ideas matter as much as the ideas themselves.

It is weaker if you expect perfect automation on day one. The first few ingests need supervision. Naming conventions will evolve. Some pages will be messy early on. That is normal. Karpathy is explicit that the gist describes a pattern, not a rigid implementation.

That is why the first version should stay small. Do not overbuild search. Do not overdesign the schema. Do not import your entire digital life in one weekend. Start with ten sources. Make sure ingest, query, and lint feel natural. Then expand.

My take

What I like about this pattern is that it fixes the part of knowledge systems that humans usually avoid: maintenance. Reading is interesting. Thinking is interesting. Updating fifty interlinked notes is not. LLMs are much better at that kind of repetitive editorial work, which is why this setup feels useful instead of theoretical.

So if you want a practical starting point, do this.

• Create a vault. Hand your agent the llm-wiki gist.

• Let it generate the schema and the first structure.

• Clip one article into raw/articles.

• Run ingest.

• Open the graph.

• Read the index.

• Ask a question that requires synthesis. Then save the useful answer back into the wiki.

That is enough to feel the difference.

If you build this, pair it with the tools you already use every day.

When I first read Sequoia’s latest thesis, “Services: The New Software,” I was skeptical. Another prediction about AI replacing jobs? But as I read, I realized this was different. The viewpoint they present isn’t just about automation; it’s a fundamental shift in how we value human capability.

The core premise is undeniable: the next trillion-dollar company won’t be a SaaS giant selling you a better dashboard. It will be a software company masquerading as a services firm, selling you the completed work itself.

“A company might spend $10K a year for QuickBooks and $120K on an accountant to close the books. The next legendary company will just close the books.” [1]

This shift from selling tools (Copilots) to selling outcomes (Autopilots) is going to rewrite the rules for every agency, consultancy, and professional services firm on earth. Here is why this matters, and how it changes the game for builders and buyers alike.

Check out my previous articles and subscribe to keep yourself updated with the latest happenings.

Subscribe now

The Intelligence vs. Judgment Divide

The most profound insight from the report is the distinction between intelligence and judgment.

“Writing code is mostly intelligence. Knowing what to build next is judgement. Translating a spec into code, testing, debugging: the rules are complex but they are rules. Judgement is different. It requires experience and taste, instinct built on years of practice. Deciding which feature to build next, whether to take on tech debt, when to ship before it’s ready.” [1]

Writing code, translating a spec, testing, and debugging - these are acts of intelligence. The rules are complex, but they are still rules. AI is exceptionally good at learning rules.

Judgment is entirely different. Judgment is deciding which feature to build next. It’s knowing when to take on technical debt to hit a market window, or having the taste to know when a product is ready to ship. Judgment is instinct built on years of practice.

As AI commoditizes intelligence (the how), the market value is rapidly shifting to judgment (the what and why). Sequoia puts it plainly: “Today’s judgement will become tomorrow’s intelligence.” [1]

This creates a fascinating paradox for the workforce. If AI handles the “grunt work” of intelligence, how do junior professionals ever develop the experience required for high-level judgment?

We are entering an era where companies will place a massive premium on seasoned professionals who possess this taste. However, freshers still hold a unique advantage: they approach problems from first principles, unburdened by “how it’s always been done,” allowing them to innovate in ways experienced veterans might miss entirely.

Copilots vs. Autopilots: The Architecture Shift

The transition from intelligence to judgment is driving a massive shift in product architecture.

“A copilot sells the tool. An autopilot sells the work.” [1]

Until recently, AI models were still developing intelligence and judgment, so the right approach was to build a copilot first: put AI in the hands of a professional and let them decide what to do with it. Companies like Harvey sell to law firms, and Rogo sells to investment banks. The professional is the customer, the tool makes them more productive, and they take responsibility for the output.

Today, the models are intelligent enough that in some categories the best place to start is as an autopilot. Crosby sells to the company that needs an NDA drafted, not to outside counsel. WithCoverage sells to the CFO who needs insurance, not to the broker. The customer is buying the outcome directly.

The higher the intelligence ratio in any field, the sooner autopilots will win.

The 6:1 Ratio: Why Services Are the Real Prize

If you want to understand why AI companies are pivoting to services, look at the math.

The work budget in any profession dwarfs the tool budget. Traditional SaaS companies fight viciously over that single software dollar. AI-native service providers (Autopilots) are bypassing that fight entirely and capturing the six-dollar work budget from day one.

The customer doesn’t want to buy a tool and learn how to use it; they want to buy the outcome directly.

This is the fundamental reason why the next $1T company won’t be a SaaS platform - it will be an AI-native services firm.

The Outsourcing Wedge: Vendor Swaps vs. Reorgs

So, where does this revolution start? It starts with outsourced work.

The playbook is clear: companies should start with the outsourced, intelligence-heavy task. Nail distribution. Expand toward the insourced, judgment-heavy work as the AI compounds. The outsourced task is the wedge. The insourced work is the long-term TAM.

Crosby started with NDAs: a well-defined task, primarily intelligence, that most companies already outsource to external counsel. The budget exists, the scope is clear, the ROI is immediate, and the substitution is frictionless. [1]

This is why the initial wave of AI disruption isn’t targeting internal teams; it’s targeting the BPOs, the external agencies, and the managed service providers.

The Opportunity Map: Where Autopilots Are Winning Now

Sequoia maps out the massive TAM across various service verticals. Here is a look at where the autopilot revolution is already taking hold:

Source: Sequoia Capital, “Services: The New Software” (2026)

The agent deployment picture is equally revealing:

Source: Sequoia Capital, “Services: The New Software” (2026)

Software engineering got to autopilot first because it’s primarily intelligence work. Every other profession is following the same path, just a few years behind.

The Boutique Revolution: Small Teams, Massive Output

What does this mean for the future of the services sector? We are about to witness the rise of the “Boutique Agency” on steroids.

The traditional model relied on massive headcount to scale revenue. Giants like Accenture or TCS built empires on this premise. But in the AI-native era, team size is no longer correlated with output.

A 10-person specialised agency, armed with the right AI agents, can now deliver the volume and quality of a 500-person firm. The team size shrinks, but the capacity to deliver massive projects expands. Unless the legacy giants radically change how they operate, these hyper-efficient boutique firms will start winning their contracts.

This is also correlated with the wave of layoffs we’ve seen at large IT services companies. It isn’t just a market correction - it’s a structural shift. The companies that adapt fastest will survive. The ones that don’t will find their margins eroded by 10-person startups operating at 10x their efficiency.

The Rise of the Architect-PM

This shift also redefines the most valuable roles in tech. For the first time, we might need more Product Managers than traditional Software Engineers.

If AI is writing the code, the “Engineering” role evolves. The new elite builder is an “Architect-PM” - someone who possesses the technical IQ to architect complex systems, combined with the deep user empathy required to solve real human pain points. They aren’t just translating specs into code; they are solutioning what the user actually needs.

The best professionals in the next decade won’t be the ones who can write the most code. They will be the ones who can ask the right questions, understand the user’s pain at a deep level, and architect a system that solves it elegantly.

Who Wins, Who Gets Disrupted

The services sector is about to be split into two camps:

Winners: AI-native autopilot companies in high-intelligence verticals (insurance, accounting, legal, healthcare billing, IT support). Boutique agencies with deep domain expertise and AI fluency. Senior professionals with strong judgment and taste. Freshers who embrace first-principles thinking over conventional wisdom.

Under Pressure: Large BPOs and IT services firms that rely on headcount arbitrage. Mid-level professionals in purely intelligence-heavy roles (basic coding, data entry, form processing, standard contract drafting). Traditional SaaS tools that sell to professionals rather than directly to outcome-buyers.

The Verdict

Sequoia’s thesis is a wake-up call. The era of selling software as a tool is peaking. The era of selling software as a service - literally doing the work - is just beginning.

Whether you are building an AI startup or running a services firm, the mandate is clear: stop selling the hammer, and start selling the house.

The companies that understand this shift early will capture the six-dollar budget. The ones that don’t will keep fighting over the one-dollar budget - and wonder why growth is slowing.

References

[1] Sequoia Capital. “Services: The New Software” by Julien Bek. Published March 5, 2026. https://sequoiacap.com/article/services-the-new-software/

We spent the last decade moving everything to the cloud. We traded local files for Google Docs and native apps for browser tabs. The browser became the operating system. It made collaboration easy, but it created a massive problem for AI: the cloud is a sandbox.

Cloud apps cannot see your local files. They cannot run your terminal. They cannot click your native apps. To do real work, an AI agent needs to break out of the browser tab and live in your /Users/folder.

This is the desktop renaissance. We are moving from “Chat-in-a-Box” to “Agent-on-the-Metal.” And it all started with a viral script.

The OpenClaw Catalyst

OpenClaw went viral for a reason. It proved that users want an agent that can take over their mouse and keyboard to execute multi-step workflows. Before OpenClaw, we asked AI questions. After OpenClaw, we assign AI jobs.

I documented my own journey with OpenClaw in “How am I using OpenClaw to run TheToolNerd,” where I built a “Mission Control” system with multiple specialized agents—Scout finds new tools, SteveJobs prioritizes them, and Ralph builds features. The system works 80% of the time, but when it does work, it’s magical. Having an agent find tools while you sleep, prioritize your morning, and build features from a sentence—that’s the future.

The virality of OpenClaw also sparked an entire ecosystem of wrappers. In “The OpenClaw Wrapper Bubble,” I tracked how 10+ SaaS platforms hit $20K+ MRR in days by simply making OpenClaw easy to deploy. This shows the raw demand for desktop agents.

Now, every major AI company is scrambling to build their own, more reliable, enterprise-ready version of a “Computer-Using Agent.” They realize that whoever controls the desktop controls the workflow.

Don’t just keep up with AI—stay ahead of it. Subscribe now to get the most important updates, trends, and breakthroughs straight to you.

Subscribe now

Top Desktop AI Agents in 2026

1. Claude Desktop (with Claude Code & Co-work)

The Enterprise-Ready Leader

Anthropic didn’t just build a desktop app—they built the foundation for the entire “Computer Use” revolution. Claude Desktop features direct “Computer Use” API integration, which means Claude can literally take over your mouse to click, type, and scroll through your screen like a human would. But the real power lies in two specific products: Claude Code and Claude Co-work.

Claude Code runs in your local terminal and understands your entire codebase without uploading it to a server. This is the terminal-based product that started the revolution.

Anthropic had this vision a long time ago: if you can control the whole computer from the terminal—every file, every folder, every structure—then you have a true general-purpose agent. Claude Code proved this works. It can read your project structure, understand your architecture, and write code that fits seamlessly into your existing system.

For non-techies, Claude Co-work is the game-changer. It’s Claude’s way of saying, “I’ll handle the boring stuff.” It manages your calendar, drafts emails, schedule tasks, organizes local files, and handles repetitive tasks without requiring you to understand how it works under the hood. You just describe what you want, and it does it. This is transforming work for people who’ve never touched a terminal.

Claude is currently winning the enterprise trust game because they prioritize safety alongside capability. They understand that giving an agent OS-level access is a massive responsibility.

Download: claude.ai/download

Read more: Claude CoWork: The AI Agent That Automates Your Mac

2. OpenAI Codex App

The Multi-Agent Command Center

This is a dedicated macOS and Windows app, separate from ChatGPT. OpenAI designed it specifically for managing multiple AI agents working in parallel on complex coding and system tasks. It features built-in worktrees and parallel execution. Think of it as a “command center” where you can spawn multiple agents, each with its own workspace, each working on different parts of your codebase simultaneously. It treats your OS as a canvas for agentic swarms.

Download: openai.com/codex

3. Manus Desktop (My Computer)

The Polished General Worker

Manus brought the OpenClaw vision to a polished, consumer app. The “My Computer” feature gives it direct access to local folders. It executes CLI commands, manages files, and automates workflows across your entire PC seamlessly.

Unlike the raw power of OpenClaw, Manus feels like a finished product. It handles the messy reality of local file management—moving files, organizing folders, executing batch operations—without the debugging headaches. It’s the tool you can actually trust with your important files.

Download: manus.im/desktop

Read more: Manus is better than OpenClaw for you

4. MiniMax Agent

The Expert Agent Workbench

China’s answer to the OpenClaw virality. MiniMax built a dedicated desktop app that batch-processes local files, executes terminal commands, and maintains persistent memory of your OS activities.

But MiniMax went further—they launched MaxClaw, their own version of OpenClaw, built directly into their agent ecosystem.

It includes 5000+ pre-built skills, allowing you to chain complex workflows without writing a single line of code.

MiniMax integrated its latest proprietary models (MiniMax 2.7), optimized for lower cost and high-throughput workflows. The platform focuses on reliability and structured task execution, making it well-suited for batch processing and repeatable agent workflows.

Download: agent.minimax.io/download

5. Perplexity Computer

The Long-Horizon Researcher (Recently Launched)

Perplexity just made a serious move with Perplexity Computer in Feb 2026 - a system designed to go beyond chat and actually execute work. Perplexity AI positions it as a general-purpose “digital co-worker” that breaks goals into tasks, spins up sub-agents, and runs them in parallel across tools and environments.

Under the hood, it orchestrates multiple AI models, routing each step to the best one for reasoning, research, or execution. Each task runs in an isolated environment with access to a real browser, filesystem, and integrations—making it capable of handling long-running workflows with minimal supervision

Download: https://www.perplexity.ai/computer/new

6. GenSpark Browser

The Agentic Workspace

GenSpark positions its desktop app as a “Super Browser” for macOS. It features an “Autopilot Mode” that autonomously handles phone calls, creates slides, and manages docs locally. While others focus on code and research, GenSpark is building the “creative agent”—one that can handle the full workflow from brainstorming to presentation.

Download: genspark.ai/browser

7. Skywork Desktop

The Silent OS Operator

A full desktop agent that runs quietly in the background. Skywork executes multi-step workflows across Mac and Windows, acting as a reliable digital twin for repetitive OS-level tasks. It’s the agent you set and forget.

Download: skywork.ai/desktop

8. ChatGPT Desktop App

The Gateway to Local Context

While not a full OS-controller yet, the ChatGPT desktop app is the trojan horse for OpenAI’s broader agentic ambitions. With deep OS integration (like Option+Space on Mac), voice mode, and the ability to read local screen context directly from your IDE, it bridges the gap between chat and local context. It’s the entry point to OpenAI’s agentic vision.

Download: chatgpt.com/download

The “Claw” Wars: Everyone is Building Their Own Version

The OpenClaw effect didn’t just inspire desktop apps—it sparked a full ecosystem of “Claw” variants. Every major AI company is now building their own version, optimized for their strengths.

Kimi Claw (Moonshot AI) launched a browser-native platform that runs OpenClaw agents 24/7 without local hardware. It’s designed for users who want the power of OpenClaw but prefer a cloud-hosted solution. Kimi Claw includes pre-built skills and integrates Moonshot’s K2.5 model, making it a cost-effective alternative for developers.

MaxClaw (MiniMax) is MiniMax’s proprietary version of OpenClaw, built directly into their agent ecosystem. It focuses on reliability and includes expert skills for batch processing, terminal execution, and persistent memory management.

KiloClaw (Kilo Code) takes a different approach—it’s a hosted OpenClaw service that deploys in seconds with 500+ models, enterprise security, and zero DevOps required. You can spin up a full OpenClaw instance in less than 20 seconds without touching the terminal.

For enterprise readiness, NVIDIA NemoClaw is a game-changer. NVIDIA announced NemoClaw at GTC 2026 as an enterprise-focused software stack that adds security and privacy controls to OpenClaw. NemoClaw installs in a single command and provides sandbox isolation, a “privacy router,” and compliance features that make OpenClaw suitable for production environments. It’s NVIDIA’s way of saying, “OpenClaw is powerful, but here’s how to run it safely in your enterprise.”

The message is clear: OpenClaw proved the concept. Now, everyone is racing to build the most reliable, secure, and user-friendly version.

The China Play: Localization and Control

While Western companies are building more reliable versions of OpenClaw, China’s tech giants are doing something different. They’re not just adopting OpenClaw—they’re localizing it, monetizing it, and integrating it into their super-apps to maintain control over the AI agent ecosystem.

Tencent, ByteDance, and Zhipu AI are taking a different approach. Instead of focusing purely on standalone desktop agents, they are integrating agent capabilities directly into their existing ecosystems—messaging platforms, cloud infrastructure, and model APIs.

The strategy is not just to build better agents, but to control distribution. By embedding agent functionality into platforms users already rely on, they create tightly integrated environments where workflows, data, and models are all connected.The

Agentic OS Layer

We are building a new layer in the technology stack.

At the bottom, you have your Operating System—your files, your terminal, your native apps. At the top, you have the Human User, assigning high-level goals. In the middle sits the Agentic OS Layer. Tools like Manus, Claude, Codex, and Perplexity act as the bridge. They translate intent into clicks, keystrokes, and terminal commands.

Cloud AI is blocked by a firewall from your local files. Desktop AI has direct access. That access changes everything.

The Million Dollar Question: Safety vs. Utility

Giving an agent “Screen Vision” and terminal access is like giving a stranger the keys to your house. Is it safe?

We are trading privacy for extreme productivity. The winners in this space won’t just be the smartest models. They will be the ones that build the most trusted sandboxes and permission layers. This is why Claude is currently winning the enterprise trust game. They prioritize safety alongside capability. NVIDIA’s NemoClaw is another signal—enterprises are demanding security wrappers around these powerful agents.

You have to decide if the speed is worth the access. For most developers and builders, the answer is yes. But for sensitive data or mission-critical systems, you need to choose carefully.

The Verdict

The browser isn’t dead. But it is no longer the only place work happens.

Mastering one of these desktop agents will be the defining productivity skill of 2026. You need to learn how to manage a digital worker that lives on your machine. Whether you choose Claude for enterprise trust, Manus for polish, Perplexity for long-horizon research, or one of the “Claw” variants for cost-effectiveness, the choice is yours.

Pick one. Download Claude Code, install Manus, or set up the Codex app. Give it a local folder and a messy task. Watch it work. You will understand why the desktop era is back.

The future isn’t in the cloud. It’s on your desktop, working while you sleep.

The research is solid - it’s available on Amazon if you want to dive deep - but I wanted to turn that methodology into something functional. Something more than just a generic dashboard

.

This is the story of how I used a combination of AI tools to transform doctoral thesis into a full-scale enterprise application called The Bridge OS - by Ainapur.

The Before and After

Before we dive into the build, here’s a look at the transformation. We went from a static consulting methodology to a dynamic, AI-powered operating system.

Visit : Ainapur

Why did I select Lovable?

I’ve spent sometime testing AI builders for building this app. I’ve started with Anything, but my initial prototype wasn’t that good. Then I tried with Lovable, and the first proto it built was very simple and interesting, and then I decided to build on it.

Subscribe now

I also had some credits to use accumulated by non-usage, and honestly, I was impressed by how much the platform has evolved. I am a fan of Claude Code & Replit , but Replit can consume credits fast if you aren’t careful and Replit doesnt have credits rollover, even if I don’t use them. Lovable’s initial design felt right for an enterprise-grade tool.

Step 1: The Vision and the Prompt

I started with a basic prompt to scaffold the skeleton:

“I want to build a Balanced ScoreCard application, where any company can build, design their balanced scorecard with strategy map and an implementation plan.

Output should be like the image attached. I should be able to connect the arrows, etc..

Read a lot about Balanced Score Card. It should be an AI Chatbot, with which users can chat and build their scorecard.

Think about the idea, and the design .. how it will work in HTML CSS style before coding.”

Lovable - created a plan for me and once approved, within minutes, Lovable gave me a working React + TypeScript + Tailwind CSS stack. I asked it to work only on Design and not the backend.

It was a good start, but it was generic. It didn’t have the “soul” of my dad’s methodology yet.

Step 2: Injecting Domain Expertise

This is where the magic happened. I didn’t just want a BSC tool; I wanted a tool that understood the domain.

I uploaded my dad’s PhD thesis as a reference document. Lovable parsed the content and used it to shape the data model. Suddenly, the AI assistant wasn’t just giving generic business advice - it was referencing Kaplan & Norton’s framework and understanding the specific cause-effect linkages.

I also brainstormed with Google Gemini to nail down the product name and positioning. We landed on The Bridge OS - the operating system that bridges the gap between strategy and execution.

Step 3: Designing UI with Magic Patterns

A tool for enterprise clients can’t look like a weekend hackathon project. I used Magic Patterns to define the design system based on the problem statement I created with Gemini.

I had long conversations with it and once I was satisfied I asked it to write a design guide, that I pasted back in Lovable to build it

Step 4: Designing Logo with Claude

For the logo, I actually turned to Claude. While Gemini and other platforms struggled to create something I liked, Claude was incredible at generating SVG logos.

The beauty of SVG is that you can edit it directly - no more fighting with “nano banana” style pixelated generations.

Step 5: Creating the Launch Video

I have asked Lovable to create a launch video as well. You read it right — Lovable for building the launch video. It already had context about my application and I have given it the product screenshots and asked it to create it into a video.

It used the Remotion Dev skill to do it. However, I have added the music using Descript

Lovable has recently launched an updated version of their app to go beyond just building apps.

The Workflow: From Idea to Execution

To explain how everything fits together, I put together this infographic:

Feature Deep-Dive: What We Built

1. The AI Consultant

The heart of the platform is an AI chat assistant that understands the thesis. It doesn’t just list bullet points; it maps strategic objectives to the four BSC perspectives - following the guideline defined in the book.

2. Interactive Strategy Maps

Visualizing cause-effect relationships is crucial for executives. The Bridge OS generates these maps automatically based on the objectives defined in the scorecard.

3. SWOT Analysis & Matrix

AI-generated SWOT with a strategy formulation matrix. Not just a list of bullet points - actual strategic options derived from the intersection of internal capabilities and external factors.

4. Gap Analysis & Benchmarking

Compares current state against industry benchmarks and best practices. Identifies where the organization falls short and what initiatives are needed to close the gaps.

5. Full Balanced Scorecard

The complete BSC table with strategic objectives, KPIs, current values, targets, and strategic initiatives. Everything an organization needs to track strategy execution in one view.

6. Department Cascading

This was a key takeaway from the PhD research. The platform allows the CEO-level BSC to cascade down to HR, Operations, and Finance, ensuring full organizational alignment.

My Verdict

Building this taught me one major lesson: No single AI Tool is a Magic .. we need a combination of different tools with different capabilities to build something really interesting.

Anyone can prompt an AI to build a dashboard.

If you’re sitting on specialized knowledge - whether it’s a thesis, a book, or years of experience - the barrier to turning that into a product has never been lower.

“Create a skill to write test-driven development cases for any feature.”

That was the full prompt. No spec document, no example files, no instructions on how to build it. Claude took that single line and handled everything — writing the skill, testing it, comparing results, and packaging a .skill file ready to use. This is what that process looked like.

The one-prompt demo is impressive — but that’s not how I usually build skills. My workflow is at the end of the article

What My Test Driven Development Skill Does

The finished skill, called tdd-writer, gives you this whenever you describe a feature:

• A full test file in whatever framework your project uses (Jest, pytest, Go testing, RSpec...)

• Tests in the right order: happy path first, then edge cases, then error scenarios

• A one-liner to run the tests immediately

• A short list of what you need to build to make them pass

No implementation code. Only failing tests that define what the code should do — the way TDD is supposed to work.

If you would like to know more about Claude Skill 2.0 , check out this article

Subscribe now

How Claude Built the Skill - Skill Creator Workflow

The workflow Claude follows when using skill creator looks like this:

1. Wrote the Skill File

The first thing Claude produced was SKILL.md — a plain text file that acts as the skill’s brain. The top section (frontmatter) tells Claude when to use it:

---
name: tdd-writer
description: >
  Writes test-driven development (TDD) cases for any feature before
  implementation code exists. Trigger on phrases like "write tests for",
  "tests before code", "help me TDD this", or when a user describes a
  feature and asks how to approach it.
---

The rest of the file contains the actual instructions — things like: detect the test framework from the project files, write tests in happy-path-first order, never write implementation code.

That last rule got its own dedicated section:

## What NOT to do

- Don't write implementation code. If you find yourself writing the
  actual feature, stop.
- Don't write tests that always pass (e.g. `assert True`).
- Don't mock everything — only mock at system boundaries.

2. Created Test Prompts

Next, Claude wrote three realistic prompts to check whether the skill actually works. These aren’t hypothetical — they’re the kind of messages a developer would actually send:

1. Python password validator — check for min length, uppercase, digits, special characters

2. Jest shopping cart — an addItem function that handles duplicates and rejects bad prices

3. Go database query — FetchUserByID using testify, with proper error types

3. Ran Two Agents Per Prompt (in Parallel)

For each of those three prompts, Claude launched two subagents simultaneously — one with the skill loaded, one without.

The idea: if the skill is doing its job, the outputs should be noticeably better.

Here’s what the skill produced for the Python prompt:

"""
TDD tests for password_validator module.
All tests should currently FAIL (Red phase).

Run with:
    pytest test_password_validator.py -v
"""

import pytest
from password_validator import validate_password

# Happy path
def test_valid_password_returns_true():
    # Arrange
    password = "Abcdef1!"
    # Act
    result = validate_password(password)
    # Assert
    assert result is True

# Edge case — boundary value
def test_valid_password_exactly_eight_characters_returns_true():
    password = "A1!bcdef"  # exactly 8 chars, all rules satisfied
    assert validate_password(password) is True

# Error case
def test_none_input_raises_type_error():
    with pytest.raises(TypeError):
        validate_password(None)

And it closed with a plain-English reminder of what to do next:

Red:      Run the tests now — they should all fail. That's correct.
Green:    Implement the minimum code to make each test pass, one at a time.
Refactor: Once all green, clean up. The tests protect you.

The baseline agent (no skill) produced equally good test code. What it skipped: the run command, the “what to implement” list, and the Red-Green-Refactor reminder at the end.

4. Graded and Reviewed

Each run was scored against six assertions — things like “test names are descriptive,” “no implementation code was written,” and “run instructions are included.” Results went into an eval viewer:

The 28% gap traces back to one thing: the skill consistently added the scaffolding — run instructions, implementation roadmap, Red-Green-Refactor — that plain Claude left out.

5. Packaged

One command:

python3 -m scripts.package_skill ~/.claude/skills/tdd-writer

✅ Skill is valid!
✅ Successfully packaged to: tdd-writer.skill

The skill was already active in the Claude Code session from the moment it was created. No restart, no configuration.

How I Actually Use Skill Creator (In Practice)

In reality, I work with Claude step by step, just like I would with a developer:

• I start with a task (e.g., generate tests, extract data, structure output)

• I refine the output through multiple iterations

• I correct edge cases, improve structure, and push it toward what I actually need

• I don’t touch the implementation manually — I let Claude handle everything

Only once I’m fully satisfied with the behavior…

👉 I ask Claude to convert that workflow into a reusable skill.

So instead of:
“Create a skill from scratch”

The real pattern is:
“Refine a workflow → Lock it in as a skill”

That’s the shift.

Skills aren’t where you start —
they’re what you create after something works reliably.

The Whole Thing Took One Prompt

The user typed: “Create a skill to write test-driven development cases for any feature.”

Claude wrote the skill, designed the test cases, ran six parallel agents, graded the outputs, opened the review UI, and packaged the result. The only human input after the initial prompt was a single word: “approved.”

That’s what skill creator is for.