There is a tempting thought when using Claude Code or Codex: why am I building an agent loop when these companies already operate one?

I want an agent that can investigate a problem, use tools, keep track of its work, and come back with something useful. I would rather spend my time building the product than debugging the mechanism that decides what happens after the third tool call fails.

OpenAI and Anthropic are making that trade possible. OpenAI launched its managed Agents API on September 10, exposing the harness behind Codex. Anthropic offers Claude Managed Agents. AWS also has a managed AgentCore harness — not just infrastructure on which to host your own agent. And Cursor is taking a similar approach for software engineering, exposing its coding-agent harness through the Cursor SDK and Cloud Agents.

But “use our harness” can mean several different things. Before comparing features, we need to separate borrowing the agent’s behavior from outsourcing the infrastructure that runs it.

That distinction changes the architecture, the bill, and the exit strategy.

What are we actually borrowing?

A model produces the next response or proposes a tool call. The harness runs the surrounding process: assembling context, calling the model, dispatching tools, feeding results back, and deciding when to continue, pause, or stop. More complete harnesses add context compression, filesystem access, subagents, and approval mechanisms.

The runtime is the execution environment underneath. A sandbox isolates code execution; it is not the same thing as the orchestration loop. A framework gives you building blocks for implementing that loop and its surrounding workflows (see the concept in Figure 1).

MCP standardizes a tool connection; it does not decide whether a particular user should be allowed to perform the operation. I would keep that authorization decision in the tool service, even when the harness provides additional permission controls.

A tool being available is not the same as an action being authorized.

One problem, not ten unrelated demos

Consider an incident assistant: investigate a failed checkout deployment, read logs and a runbook, cite evidence, and propose a mitigation. It must not change production without approval.

The code below contains integration fragments, not complete deployments or a performance benchmark. I have checked the API shapes against current documentation, but have not executed an end-to-end comparison. Credentials, remote-tool authentication, deployment configuration, and production error handling are omitted where they would obscure the difference.

For the local examples, save this deliberately small fixture as incident_demo.py:

TASK = (
    "Investigate checkout's failed deployment. Read the evidence, "
    "cite evidence IDs, state uncertainty, and propose a mitigation. "
    "Do not modify production."
)

def read_evidence(service: str) -> str:
    """Return read-only demo deployment evidence for a service."""
    if service != "checkout":
        return "No evidence available for this service."
    return (
        "[E1] Release 42 started at 14:02.\n"
        "[E2] Database connection timeouts increased at 14:03.\n"
        "[R1] Runbook: verify connection-pool limits before rollback."
    )

For managed services, assume this same tool is exposed through a configured, authenticated, read-only MCP server. A local Python function does not automatically become a cloud-accessible tool.

Four ways to hand over the harness

OpenAI Agents API: borrow the Codex machinery

The interesting part is not another wrapper around a model call. OpenAI manages context compaction, tool discovery and execution patterns, and optional parallel subagents. The execution environment can be OpenAI-hosted, self-hosted, or supplied by a sandbox partner.

A minimal launch looks like this:

import os
from openai import OpenAI
from incident_demo import TASK

session = OpenAI().beta.agents.sessions.create(
    agent={
        "model": os.environ["OPENAI_AGENT_MODEL"],
        "tools": [{
            "type": "mcp", "server_label": "incidents",
            "transport": {
                "type": "http",
                "server_url": os.environ["INCIDENT_MCP_URL"],
            },
        }],
    },
    environment={"type": "openai_hosted"},
    input=TASK,
)
print(session.id)  # Launches a session; consume its events separately.

The session/event model matters: your web request does not need to remain the lifetime of the investigation.

I would choose it for open-ended, tool-heavy investigations or workspace tasks when I want OpenAI to maintain the orchestration machinery. I would hesitate when I need to replace the loop’s internal decisions or require a provider-independent managed service. It is also a public beta, which belongs in the production-risk discussion.

Claude Managed Agents: delegate the session, not just the response

Anthropic separates the agent definition, execution environment, session, and events. Its managed harness includes file operations, shell access, web tools, MCP, caching, and compaction. Cloud and self-hosted sandboxes are supported. As of October 2026, the service remains in beta.

With the agent and environment already configured:

import os
from anthropic import Anthropic
from incident_demo import TASK

client = Anthropic()
session = client.beta.sessions.create(
    agent=os.environ["CLAUDE_AGENT_ID"],
    environment_id=os.environ["CLAUDE_ENVIRONMENT_ID"],
    title="Checkout incident",
)
client.beta.sessions.events.send(session.id, events=[{
    "type": "user.message",
    "content": [{"type": "text", "text": TASK}],
}])
print(session.id)  # Stream or retrieve session events separately.

The SDK supplies the required Managed Agents beta header.

I would choose it for Claude-centered research, coding, document work, or investigations that need persistent sessions without a homegrown execution service. I would not choose it merely for a short classification request. That rarely needs a managed workspace.

Data requirements can settle the question before model quality does: Claude Managed Agents is currently not eligible for Zero Data Retention. Hosting the sandbox yourself does not mean you have moved every part of the managed service into your infrastructure.

AWS AgentCore: do not confuse the harness with Runtime

AWS has three things people often collapse into one. Agents for Amazon Bedrock provides managed orchestration using facilities such as action groups and knowledge bases. AgentCore Runtime hosts your agent code. AgentCore harness supplies a configured agent loop on top of the platform.

The managed harness is powered by Strands. It supports multiple model providers and connections to AgentCore capabilities such as Gateway, Memory, Browser, and Code Interpreter. AWS documents it as generally available in supported regions.

With a harness and its read-only tools already deployed:

import os, uuid
import boto3
from incident_demo import TASK

client = boto3.client("bedrock-agentcore", region_name="us-west-2")
response = client.invoke_harness(
    harnessArn=os.environ["HARNESS_ARN"],
    runtimeSessionId=str(uuid.uuid4()),
    messages=[{"role": "user", "content": [{"text": TASK}]}],
)
for event in response["stream"]:
    print(event)

That UUID is useful beyond the demo: reuse the session identifier to continue an investigation rather than accidentally creating a new conversation.

For an AWS-heavy application, this would be high on my shortlist. The appeal is model choice plus the surrounding identity, networking, tools, and operations — not a claim that AWS’s reasoning is intrinsically better.

There is also an escape route: export the harness to Strands code and run it on Runtime when configuration becomes limiting. That is useful, although it is not an automatic migration of every dependency away from AWS.

Cursor: borrow the coding harness

Cursor is another interesting option, particularly when the agent’s job is software engineering. With the Cursor SDK, developers can use the same agent harness behind Cursor’s IDE and CLI from their own applications. It supports codebase context, tools, MCP, hooks, and subagents, with execution either locally or in Cursor’s cloud.

Cursor Cloud Agents can work inside isolated development environments, modify code, run tests, and create pull requests. That makes Cursor attractive for tasks like investigating a failed deployment, identifying a regression, implementing a fix, and validating the changes.

I would consider Cursor for coding-heavy automation, especially when the workflow revolves around repositories and CI/CD. I would be less inclined to use it for a general-purpose business agent, where a less specialized harness might be a better starting point.

The SDK and Cloud Agents API are still in public beta, and usage follows Cursor’s model-based pricing.

import { Agent } from "@cursor/sdk";

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  local: { cwd: process.cwd() },
});

const run = await agent.send(
  "Investigate the checkout deployment regression. Do not modify production."
);

console.log((await run.wait()).result);

And the OpenAI and Claude SDKs?

They are not synonyms for the managed services. OpenAI’s Agents SDK is a code-first orchestration library with tools, handoffs, guardrails, and tracing. Claude’s Agent SDK exposes the agent loop and capabilities behind Claude Code as a library. You can borrow those abstractions while retaining responsibility for deployment and isolation.

That middle ground is easy to miss: you do not have to choose between a managed API and writing everything yourself.

A quick rule of thumb:

If the work is open-ended and the agent needs to manage its own tools, context, and execution, I would start by evaluating a managed harness. If the product requires explicit workflows, approval steps, or strict output contracts, I would lean toward a code-first framework. And for a simple, bounded task, I would first ask whether I need an agent at all.

Six alternatives when you want more ownership

Deep Agents: a ready-made harness you can customize

LangChain’s Deep Agents is closer to a prepared harness than a blank workflow canvas. It supplies filesystem-oriented capabilities, context management, and subagents, using LangGraph underneath. Explicit to-do planning can be added through middleware.

from deepagents import create_deep_agent
from langchain.agents.middleware import TodoListMiddleware
from incident_demo import TASK, read_evidence

agent = create_deep_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[read_evidence],
    middleware=[TodoListMiddleware()],
)
result = agent.invoke({"messages": [{"role": "user", "content": TASK}]})

I would use it when the job benefits from a workspace, substantial context, and delegation, but I want to own or change the harness. I would avoid the extra machinery for a narrowly bounded extraction task. Filesystem abstractions also do not remove the need to provision and secure real execution environments.

LangGraph: make the workflow explicit

LangGraph is a lower-level orchestration runtime, not a preconfigured autonomous worker. Its useful distinction here is explicit state and control flow, with persistence and interruption mechanisms.

For our incident assistant, an approval node could be:

from langgraph.types import interrupt

def review_mitigation(state: dict) -> dict:
    decision = interrupt({
        "proposal": state["proposal"],
        "evidence": state["evidence"],
    })
    return {"approved": decision is True}

This belongs inside a graph configured with a durable checkpointer and a thread identifier. Resume it through an authenticated application path; the snippet is not a complete authorization system. Nodes can restart when resumed, so external side effects need careful placement and idempotency.

I would use it when “investigate → review → authorize” is a requirement, not a suggestion. I would not start here merely to reconstruct defaults another harness already provides.

Strands: a compact loop without committing to managed orchestration

Strands offers a model-driven agent loop with Python tools and multiple model providers. Hooks let developers inspect or alter behavior at lifecycle boundaries.

import os
from strands import Agent, tool
from strands.models import BedrockModel
from incident_demo import TASK, read_evidence

agent = Agent(
    model=BedrockModel(model_id=os.environ["BEDROCK_MODEL_ID"]),
    tools=[tool(read_evidence)],
)
print(agent(TASK))

Configure AWS credentials, region, and an accessible Bedrock model before running this example.

I would use Strands when I want a small amount of agent code and an AWS-friendly deployment path while retaining control of the application. I would not mistake that short script for a complete production platform. Hosting, isolation, persistence, and operational policies still need a design.

Pydantic AI: make the output a contract

For an agent inside a backend service, I often care less about its persona than whether the next component receives a usable object. Pydantic AI supports typed dependencies, tool arguments, and validated structured outputs across multiple providers.

from pydantic import BaseModel
from pydantic_ai import Agent
from incident_demo import TASK, read_evidence

class IncidentReport(BaseModel):
    hypothesis: str
    evidence_ids: list[str]
    proposed_action: str

agent = Agent("anthropic:claude-sonnet-4-6", output_type=IncidentReport)
agent.tool_plain(read_evidence)
report = agent.run_sync(TASK).output

A successful result has the declared structure; an unsuccessful run can still raise an error. And structural validation does not prove that the hypothesis is correct or that the cited evidence supports it.

I would use it for typed backend integrations and bounded agent services. I would not expect the basic agent declaration to provision a secure, long-running cloud workspace.

CrewAI: useful roles, not an imaginary org chart

CrewAI organizes work through agents, tasks, crews, and Flows. Its documentation recommends Flows for production structure, with crews doing work inside those steps.

The smallest crew for the same investigation is:

import os
from crewai import Agent, Crew, Task
from crewai.tools import tool
from incident_demo import TASK, read_evidence

investigator = Agent(
    role="Incident investigator",
    goal="Produce an evidence-backed diagnosis",
    backstory="A cautious engineer who distinguishes evidence from guesses.",
    tools=[tool("read_evidence")(read_evidence)],
    llm=os.environ["CREW_MODEL"], max_iter=5,
)
investigation = Task(
    description=TASK,
    expected_output="Diagnosis, evidence IDs, and proposal",
    agent=investigator,
)
result = Crew(agents=[investigator], tasks=[investigation]).kickoff()

Roles and tasks become valuable when the work genuinely separates into investigation, technical review, and communication. Those abstractions are supported directly rather than being naming conventions around functions.

I would use it for meaningful delegation inside a controlled process. I would avoid adding agents just to simulate a department. Every additional model conversation should earn its cost through a measurable improvement.

Google ADK: agent development with a broader application toolkit

Google ADK combines agent definitions, tools, sessions, evaluation, and workflow composition. It is open source and designed for model and deployment flexibility, although Gemini and Google’s ecosystem are natural integration points.

In an ADK project’s agent.py:

import os
from google.adk.agents.llm_agent import Agent
from incident_demo import TASK, read_evidence

root_agent = Agent(
    name="incident_investigator",
    model=os.environ["GEMINI_MODEL"],
    instruction=TASK,
    tools=[read_evidence],
)

The ADK runner or development interface executes this definition; constructing root_agent alone does not start the investigation.

I would use it when its development tooling and workflow primitives fit the team’s platform. I would not switch a functioning stack solely because another provider now has a framework. Sequential, parallel, and loop workflows are useful capabilities, not a reason to migrate on their own.

The harness can be free. The agent is not.

There are at least five items in the bill: model inference, tools, execution, state/observability, and engineering time. “No harness fee” describes only part of that equation.

Here is a deliberately small estimate. Assume 10,000 investigations per month, each consuming 20,000 input tokens and 2,000 output tokens across its entire run. At an illustrative $3/$15 per million input/output tokens, inference is $900. These are Claude Sonnet 4.6’s published base rates, not a shared price available across every vendor.

If each investigation spends three minutes in Claude’s running status, that is 500 session-hours: $40 in runtime, or $940 including this token assumption, before additional tools and services. The Claude pricing documentation specifies $0.08 per running session-hour.

For an AgentCore microVM thought experiment, assume the same three-minute lifetime, one vCPU active for 30% of it, and a constant 4 GB of billable memory. The resource subtotal is approximately $32.33. This excludes models, other services, and any startup or idle lifetime beyond those three minutes. AWS does not charge inactive CPU during a wait, but memory can remain billable. See AgentCore pricing and metering.

OpenAI illustrates another budgeting trap. Its published pricing lists $0.12 for a 4 GB container per 20-minute session, while also stating that eligible container sessions are billed by the minute with a five-minute minimum. That distinction matters for thousands of short tasks, but the published wording alone does not establish which billing treatment applies to a particular Agents API environment. I would confirm the metering rule for my chosen setup rather than present one of those interpretations as the expected bill.

Cursor takes a different approach. Its SDK and Cloud Agents follow model-based usage pricing, with Cursor-managed cloud execution included rather than billed separately for VM, CPU, or memory. For Teams and Enterprise customers, third-party models also carry a $0.25-per-million-token Cursor fee. Self-hosted execution adds your own infrastructure costs. That makes Cursor interesting for coding-heavy workloads, although token consumption, model choice, and the number of agent iterations still determine the actual bill.

These numbers are not a price-performance ranking. The environments are not identical, and different models and harnesses can consume different numbers of tokens to achieve the same result. Safe reuse, caching, retries, and subagent fan-out can change the outcome.

The metric I would optimize is total cost per accepted result, including failed runs and human review — not the price of one successful-looking demo.

What none of them takes off your hands

For the incident assistant, my first release would have read-only production credentials. A proposed rollback would be data sent to a separate approval process — not a shell command the model can execute because its prompt says to be careful.

I would test missing logs, contradictory evidence, malicious instructions embedded in a runbook, revoked credentials, interrupted sessions, and duplicate tool requests. I would also check whether a budget stops execution when expected: Anthropic, for example, documents enforcement between model requests, so an in-flight request can take the session past its configured cap.

A self-hosted sandbox is not a promise of zero provider-side retention. OpenAI’s managed Agents API currently retains session state, supports US data residency only, and is not ZDR-eligible even with a self-hosted sandbox.

This is where I would look hardest before adopting any platform: the permissions boundary, the recovery behavior, the retained data, and the evidence that a completed run actually completed the business task.

So, should we borrow the harness?

For a product whose value is open-ended investigation or workspace automation, I would start by evaluating a prepared harness rather than rebuilding one. OpenAI, Anthropic, AgentCore, Cursor, and Deep Agents all belong in that conversation, with different ownership and operating models.

For a product whose value is a reliable process, I would start from the process: perhaps LangGraph for explicit transitions, Pydantic AI for typed interfaces, Strands for a compact tool loop, CrewAI for useful delegation, or ADK for its development and workflow ecosystem. The sections above describe the tradeoffs I would validate, not benchmark winners.

These choices can also compose. AWS documents a bring-your-own-code Runtime path; borrowing AWS infrastructure does not require adopting the managed AgentCore loop.

My preference is to keep the business rules and tool contracts outside the harness wherever practical. That will not make migration free, but it gives the product fewer reasons to depend on one implementation.

OpenAI and Anthropic will lend us their harness. AWS will provide one — or run ours. Open-source frameworks give us more of the machinery to shape ourselves.

Borrow the part that is not your advantage. Keep control of the part your users depend on.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com, https://medium.com/@crhisto

Right now, I have multiple subscriptions to AI coding tools. Claude Code, Codex, and Cursor are basically my main stack, and then I use other tools from time to time depending on what I am building or what has been released recently. If you are using these tools every day, it becomes surprisingly easy to justify one more subscription. The more you use them, the more attractive the next plan becomes.

When your usage starts reaching billions of tokens per month, another million tokens does not sound like much. You hit a limit and the immediate reaction is usually not maybe I should stop. It is how much is the next plan?

I have done exactly that. I have used the $200 plans (and, for reasons I’m not ready to discuss with my credit card, sometimes more…) for periods of time, and I have also tried rotating the higher, roughly $100-level plan between the tools I use the most.

Part of the reason is simply curiosity. These labs are shipping new models, agent capabilities, integrations, reasoning modes, design features, and workflows every few weeks. I want to get comfortable with them and understand what actually changed instead of just reading the release notes.

So sometimes Claude gets the bigger plan. Another month it might be another tool. I use it heavily, experiment with the new capabilities, decide what is genuinely useful, and then rotate again. I still think there is a lot of value in doing that. But after spending some time with the biggest plans, I realized something I did not expect.

Having enough tokens to keep going is not always good for me

This is not really about saving money. And I am definitely not saying that $20 is better than $100 or $200. This is simply what has started to work better for me: keep decent access to most of the tools, have a larger allowance for one of them, rotate that allowance when I want to explore something new, and accept that sometimes I am going to hit a wall.

Because I am starting to think the wall itself has some value.

When execution becomes too easy

One of the most impressive things about AI coding is how much it has reduced the cost of trying something. I can have an idea for a feature, describe it to an agent, get an implementation, test it, modify it, redesign part of it, refactor the architecture, and continue iterating without ever leaving the same workflow. That is amazing.

But I think it creates a strange new problem: when execution becomes extremely cheap, thinking before execution starts to feel expensive. Why spend thirty minutes deciding exactly what a feature should do when Claude Code can start implementing something right now? Why completely define a user flow if Claude can generate the screens and I can fix them afterward? Why spend an hour questioning an architectural decision if Codex can refactor the code later?

The model is always ready for the next prompt. And that makes continue a very dangerous button. When I had the larger plans, I noticed that I could stay inside this loop for a very long time. Generate, review, change, generate again. There was almost no external reason to stop.

You can feel incredibly productive while doing this. But producing more is not necessarily the same as making more progress. Sometimes the most useful thing that can happen is simply that the tool tells me: you are done for now.

The limit gives my brain a turn

I have noticed this particularly when doing design work with Claude. I might start with an onboarding flow. Then I create another screen. That screen makes me realize I need more information from the user, so I modify onboarding. That affects the home screen. The home screen gives me another idea. That idea creates another flow.

Very quickly, what started as a simple product produces dozens of decisions. Claude is perfectly capable of continuing. The question is whether I should.

When I hit the usage window, I obviously feel some frustration at first. Sometimes I already have the next prompt written. But because I cannot immediately execute it, I start thinking about the product instead of the next generation.

Is that information really necessary during onboarding?

Does this screen have too much information?

Would the user understand this flow?

Does this feature solve a real problem, or did I add it simply because generating it was easy?

And quite often, when the usage window becomes available again, I do not execute the prompt that was waiting. I rewrite it. Sometimes I make it much more specific. Sometimes I combine several requests into one. Sometimes I realize I should not build the feature at all.

In those cases, the limitation did not reduce my productivity. It probably saved me from spending another few million tokens building something that I would eventually remove anyway.

Token ROI is not only about tokens

This has changed how I think about the economics of these subscriptions. We normally compare AI plans by looking at how much usage we receive for $20, $100, or $200. More tokens look like more value. But maybe the better question is not how many tokens I managed to consume.

It is what I got from them. I have started thinking about this as token ROI.

If I consume five billion tokens generating features, changing them, refactoring them, and eventually deleting half of them, that may be a worse investment than consuming two billion after spending more time deciding what should exist in the first place. The constraint also changes the way I prompt. When capacity feels unlimited, my prompts naturally become lazier.

Change this.

Try another version.

Fix this.

Continue.

When I know I have limited capacity, I think more carefully before sending the next instruction. What exactly is wrong? What should remain unchanged? What problem am I actually trying to solve? What context would prevent the model from going in the wrong direction? I end up spending more human tokens before spending AI tokens. And the result is often better.

There is another limit we should probably respect

There is also a part of this that has nothing to do with software or subscription economics. These tools can make it surprisingly easy to forget that you are a human being.

If you enjoy building things, coding agents are dangerous in a very specific way: there is always one more thing you can finish. The model does not get tired. At midnight it works exactly as enthusiastically as it did at 9 a.m. If you give it another prompt at 2 a.m., it is not going to tell you that perhaps this feature can wait until tomorrow.

And if you have enough tokens, there is nothing technically forcing you to stop. I have started to see the limits as a healthy constraint for this reason too. If I hit a usage window around lunch, perhaps that is actually a very good time to have lunch. Not lunch in front of another terminal while opening a second AI tool, but lunch with friends, with my wife, or with colleagues.

If the window resets later at night, that does not mean I need to organize my life around the reset. Sometimes the correct optimization is to let the tokens sit there while I sleep. This sounds obvious when you write it down. It feels less obvious when an agent is halfway through something you are excited about.

But the same pause that improves the product can improve the person building it. Going for dinner, exercising, talking to someone, sleeping properly, or simply doing something unrelated gives your brain time to process problems in the background. When you return, you often have not only more energy but different ideas.

So I am trying to make these windows coincide with boundaries that should exist in my day anyway.

Lunch is a boundary.

Dinner is a boundary.

Time with my wife or friends is a boundary.

Sleep definitely needs to be a boundary.

Instead of thinking about those hours as time where I am not using the subscription I paid for, I am starting to consider them part of the return on that subscription. A rested brain with a good prompt tomorrow can easily be worth more than another three hours of mediocre prompting tonight.

I still want the new models

None of this means I am becoming an AI minimalist. Quite the opposite. I still want to try the newest models. I want to understand what Claude Code changes, what Codex adds, what Cursor does differently, and what new labs bring into this space.

That is one reason rotating the bigger subscription has worked well for me. I can spend some time seriously using a tool, understand its new capabilities, and then decide whether it deserves to keep receiving most of my budget.

What has changed is that I no longer feel that I need maximum capacity across every tool simultaneously. For me, having one bigger plan and reasonable plans for the rest creates a surprisingly useful amount of friction. I have enough capacity to experiment seriously, but not so much that the answer to every problem becomes send another prompt.

And again, this is simply what is working for me. Someone running dozens of parallel agents or doing large-scale production work may have completely different economics. There are absolutely situations where paying for the largest plans makes sense.

My point is more personal than that. I used to think that hitting an AI limit meant I had chosen the wrong subscription. Now I sometimes think it means I have reached a good moment to think.

Maybe we should keep some friction

The AI industry is obviously moving toward more capacity. Context windows will get bigger. Inference will get cheaper. Agents will run longer. Subscription limits will probably keep increasing.

Technically, all of that is progress. But I think we should be careful not to lose the useful behavior that today’s limitations accidentally create. The important thing is probably not the rate limit itself. It is the pause between one execution and the next. A moment where the model stops generating and I have to decide whether the next thing deserves to be generated at all.

Because the bottleneck is changing. For a long time, building software was limited by how quickly we could turn an idea into code. AI is rapidly reducing that limitation. Increasingly, the difficult part will be deciding which ideas deserve to become code in the first place.

I can always buy more tokens. What I cannot buy as easily is another good idea, another clear hour of thinking, another night of proper sleep, or the perspective that sometimes appears only after leaving the computer.

So yes, I still compare the plans. I still rotate the bigger subscription when there is a new model or feature I want to understand. And I still get frustrated when I hit a limit in the middle of something interesting.

I just do not automatically assume anymore that more is better. Sometimes running out of tokens is exactly the reminder I need to stop generating, go live my life for a while, and come back knowing much more clearly what I want to build next.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com, https://medium.com/@crhisto

Forty-five minutes after opening Base44, I had a private application with authentication, weighted scoring, two different portfolio views, an AI-assisted evaluator, GitHub synchronization, and a second version being checked against App Store guidelines. The entire web-app experiment used 15 of the 250 message credits included in the Builder plan I purchased. The first five minutes were impressive. The next forty were the real test.

Let’s face it: I did not discover Base44 through a careful comparison of every vibe-coding platform. I discovered it because I kept seeing advertisements for it everywhere. At some point, the advertising became too difficult to ignore, so I decided to understand what was behind it.

That led me to the story of Base44, its founder Maor Shlomo, and Wix’s decision to acquire the company. Wix paid approximately $80 million, with additional performance-based payments possible through 2029, and said Base44 would continue operating as a distinct product while benefiting from Wix’s resources and distribution. Suddenly, the acquisition made a lot of sense to me.

Who has not used Wix, or at least considered it, when trying to create a simple webpage without worrying about hosting, frameworks, deployment, or a development team? Wix helped make website creation accessible to people who did not want to become web developers first.

Base44 takes that idea one step further. Instead of only describing a website, the user can describe an application, its data, its users, and its workflow. The platform then attempts to build the interface and much of the system behind it. From that perspective, Wix did not simply acquire another fashionable AI tool. It acquired a possible bridge from website creation to software creation.

Editorial note: I use AI for research support, organization, visual ideation, and editing. The experiments, measurements, opinions, and final editorial decisions are my own.

Base44 is already becoming less small

Base44 is the first company in my Small AI Titans series, although the word small is already becoming questionable here. Wix reported that Base44 had reached approximately $150 million in annual recurring revenue by May 2026. It has also continued expanding into agents, integrations, model selection, production checks, mobile packaging, and its own purpose-built AI model. That is not a tiny product hiding completely outside the spotlight anymore.

However, Base44 is still much less understood than ChatGPT, Claude, Gemini, Cursor, Codex, or GitHub Copilot. Many people recognize the name from the advertising but may not know what the platform actually provides, where it performs well, or where its abstractions start becoming constraints. That makes it a good Small AI Titan: a focused product with real momentum, a potentially enormous market, and enough unanswered questions to make its future interesting.

Wix may be buying the next step after the website

Wix already provides much of what a digital business needs: websites, hosting, e-commerce, payments, bookings, analytics, marketing, and customer-management tools. Base44 could add the ability to create the custom software around those services.

This is much more interesting than another demonstration of an AI generating a dashboard. The bigger question is whether companies will continue buying a different SaaS product for every small operational problem or begin generating custom software that matches their own processes.

Base44’s founder has explicitly described the market in those terms: enabling people to create software instead of buying it could replace entire software categories. That is an ambitious claim, but after testing the platform, I understand why the company is making it.

How I tested Base44

I did not want this article to become another feature list. There are already many posts explaining Base44’s pricing, comparing it with Lovable or Replit, or showing that it can create a basic app quickly. The purpose of this test was different:

I wanted to see what happened after the first impressive prompt.

Plan: Builder, monthly billing
Price paid: $50
Application: Venture Radar
Initial generation: Less than five minutes
Total exploration time: Approximately 45 minutes
Message credits used: 15 of 250
Integration credits available: 10,000
Application visibility: Private
Additional test: Mobile-oriented rebuild and App Store-readiness scan

This was a focused product experiment, not a production benchmark. I did not conduct load testing, long-term reliability testing, a formal penetration test, or a real App Store submission. I also did not run the application with hundreds of users. My goal was to understand the range of the product and identify where the convenience came from.

Venture Radar: more than another task manager

I needed an application that was understandable but complex enough to test several parts of the platform. I decided to create Venture Radar, a private workspace where founders and product builders could capture, evaluate, and prioritize business ideas.

The concept itself was not supposed to be a new startup invention. Business-idea trackers and AI validators already exist. I selected it because it required a useful combination of data, permissions, calculations, views, and AI features. The app needed:

Venture Radar
│
├── Authentication
│   ├── Registration
│   ├── Sign in
│   └── Private user records
│
├── Ideas
│   ├── Problem
│   ├── Target user
│   ├── Industry
│   ├── Status
│   ├── Research links
│   ├── Assumptions
│   ├── Risks
│   └── Notes
│
├── Evaluation
│   ├── Market opportunity
│   ├── Competition
│   ├── Technical difficulty
│   ├── Monetization potential
│   └── Weighted final score
│
└── Portfolio
    ├── Dashboard
    ├── Search and filters
    ├── Table view
    ├── Kanban view
    └── Evaluation history

This was still a manageable prototype, but it was no longer only a landing page or a static dashboard.

The initial prompt

My first prompt described the users, the idea fields, the available statuses, the dashboard, and the privacy requirement.

Build a private web application called Venture Radar.

The application will help founders and product builders capture,
organize, evaluate, and prioritize business ideas.

Users must create an account and sign in. Every user should only
be able to access their own ideas and evaluations.

Each idea should include:

- Name
- Short description
- Problem being solved
- Target user
- Industry
- Source of the idea
- Current status
- Market opportunity score from 1 to 10
- Competition score from 1 to 10
- Technical difficulty score from 1 to 10
- Monetization potential score from 1 to 10
- Estimated time to build a proof of concept
- Main assumptions
- Risks
- Notes
- External research links

Create a dashboard showing total ideas, ideas by status,
average opportunity score, highest-potential ideas,
and recently updated ideas.

Add search, filtering, sorting, and responsive design.

Base44 spent a few seconds planning the application and generated the first version in less than five minutes.

The result was simple, but it was functional enough to continue. I could navigate between the dashboard, the ideas list, and the creation form. The application had a coherent structure rather than a collection of disconnected interface components. That first result created the thought these platforms are designed to produce:

Maybe I can actually build the complete thing here.

However, creating that feeling is easier than maintaining it. The important part was what happened when I began modifying the app.

The six iterations

I divided the experiment into controlled changes rather than asking Base44 to redesign everything in one large prompt.

This made it easier to understand which requests consumed more credits and which types of changes placed more pressure on the application.

Adding weighted scoring

The first modification was a weighted score that combined market opportunity, monetization potential, competition, and technical difficulty. High competition and high difficulty needed to reduce the score rather than increase it.

export function calculateIdeaScore({
  marketOpportunity,
  monetizationPotential,
  competition,
  technicalDifficulty
}) {
  const competitionAdvantage = 11 - competition;
  const technicalFeasibility = 11 - technicalDifficulty;

  const score =
    marketOpportunity * 0.35 +
    monetizationPotential * 0.30 +
    competitionAdvantage * 0.20 +
    technicalFeasibility * 0.15;

  return Number(score.toFixed(1));
}

This was not complicated code, but that is precisely why the example matters. A significant amount of useful business software consists of relatively simple rules connected to data, permissions, forms, views, and notifications. The logic is not revolutionary, but traditional development still requires someone to create and connect all the pieces. The scoring change used one message credit, bringing my total to 3 of 250.

Privacy and the security scan

The original prompt already said that every person should only access their own records. Base44 recognized the requirement and created the app as a private workspace.

I then reviewed the broader application dashboard, where Base44 exposes users, data, security, code, agents, workflows, logs, integrations, analytics, and API configuration.

I ran the security scan and it identified two access-related issues. Base44 explained the recommendations, and I approved the fixes. The important detail is that the scan did not silently change everything. The platform surfaced the issues and let me decide whether to apply the proposed changes.

Base44 says the scan checks for data-permission gaps, exposed credentials, login-verification gaps, package vulnerabilities, and missing browser-security controls. Its documentation is also explicit that the app owner remains responsible for reviewing the final settings. That is the correct position. AI can make security configuration easier, but it does not remove responsibility from the person publishing the application. The privacy confirmation used one more credit, taking the total to 4 of 250.

Adding the Kanban view

The fourth step added a Kanban view alongside the existing table view. The intention was not only to create another visual component. I wanted Base44 to introduce a second interaction model without removing the existing one.

A user should be able to switch views and move an idea from Researching to Validating or Building, while the status remained consistent across the dashboard and list. Base44 created the view using two message credits, bringing the cumulative usage to 6. The application remained usable after the change, but I did not perform a complete regression test across every filter and state transition. For a production system, that would be the next step.

The data-model change was the most revealing test

The initial app stored the scores directly inside each idea. Later, I asked Base44 to separate the evaluations so an idea could preserve several assessments over time. The structure moved from this:

This was the most expensive operation in the test. It consumed seven credits and pushed the total from 6 to 13. That makes sense. The request affected the entities, relationships, forms, calculations, dashboard queries, and existing application logic.

Base44 accepted the change and updated the application without requiring me to start again. However, I did not perform a formal migration audit to confirm every possible edge case or inspect a large set of existing records. That distinction matters. The result was encouraging for a prototype, but it should not be interpreted as proof that every production migration will be safe. This was also the point where the difference between generating software and maintaining software became visible. The first prompt is about speed. Structural evolution is about engineering.

Adding an AI-assisted evaluation

The final web-app feature allowed the user to ask AI for an analysis of a business idea. The evaluator was designed to return a structured response like this:

{
  "problem_clarity": 8,
  "market_opportunity": 7,
  "competition_level": 6,
  "monetization_potential": 8,
  "poc_difficulty": 5,
  "main_assumptions": [
    "The user experiences the problem frequently",
    "The proposed output is specific enough to be useful",
    "The target customer is willing to pay for the time saved"
  ],
  "main_risks": [
    "The recommendations may be too generic",
    "Existing platforms could add similar functionality",
    "Customer acquisition may be harder than product development"
  ],
  "recommended_next_step": "Interview five target users before building the full workflow."
}

Creating the feature consumed two more message credits, bringing the final construction total to 15. I verified that the feature was added to the application, but I did not run a formal consistency test across dozens of repeated evaluations. I also did not measure the integration-credit cost of sustained production usage.

That would be a useful follow-up because Base44 separates the cost of creating the feature from the cost of operating it. Message credits are used while the builder changes the application. Integration credits are consumed when the live application invokes services such as LLMs, email, files, images, video, or agents.

Where the credits actually went

The complete web experiment used only 15 of the 250 message credits included with Builder.

This was better than I expected. The model also feels reasonably transparent. Base44 shows the history, the credits used by each interaction, and the changes that need approval. There is still uncertainty because credit usage varies according to the complexity of the request and the selected model. However, it is easier to understand than raw model tokens for someone who does not want to calculate input, output, and context costs.

The Builder plan I used

I paid $50 for one month of Builder. The same plan currently costs $40 per month when billed annually, representing a 20% discount. It includes 250 message credits, 10,000 integration credits, backend functions, model selection, a custom domain, in-app code editing, and GitHub integration.

The current pricing structure is:

The pricing is simple at first, but Base44 contains two different economies. One is the cost of building and modifying the application. The other is the cost of people using the live app’s integrations.

A product may be inexpensive to create but consume many integration credits if every user interaction invokes an expensive model, analyzes files, generates images, or triggers agents. That is not unique to Base44, but it is something builders need to estimate before moving from prototype to product.

Base44 feels constrained — and that may be the point

When I looked at the code and the broader environment, I did not feel that Base44 was trying to recreate Claude Code or Codex inside a browser. It felt more constrained, more opinionated, and more guided.

That limits flexibility, but it also allows the platform to understand the application environment deeply. It controls the data layer, authentication, hosting, integrations, deployment process, and many of the tools available to the builder. A general coding agent needs to work across many languages, frameworks, cloud providers, and architectures. Base44 can concentrate on one narrower problem: creating and operating web applications inside Base44. That trade-off started making more sense when I saw the model selector.

My workspace offered automatic selection as well as Base 1 and several external models. Some stronger models were identified as consuming more credits.

Base44’s automatic mode chooses a model according to the request. Smaller visual changes can use faster models, while structural or logic-heavy changes can be routed to deeper reasoning models. Builder plans and higher can also select a model manually.

Base 1 is a strategic bet

Base 1 is Base44’s own model, trained specifically for building web applications inside its environment. The company says the goal is not to create another general-purpose frontier model. Base44 can optimize for app creation because it observes the complete feedback cycle: what users requested, what the system built, what broke, what people changed, and whether the final application worked.

That is an interesting strategic decision. Base44 now wants to own the model, builder, database, backend, and deployment environment. It is becoming a vertically integrated vibe-coding platform. Owning more of the stack could improve latency, reliability, cost control, and product quality. It could also become expensive because Base44 must remain competitive across several technical layers simultaneously.

For the user, the immediate benefit is clearer: the model does not need to understand every possible software environment. It needs to understand Base44 exceptionally well.

GitHub integration took very little effort

I configured GitHub during the experiment. Base44 created a repository, made the initial commit, and synchronized the project automatically. That is important because code access creates a path beyond conversational editing. A developer can inspect the generated project, clone it, work locally, and merge changes into the main branch for synchronization back into Base44.

I did not complete a long-term experiment involving manual changes followed by many subsequent AI modifications. Therefore, I cannot say how well every hand-written customization survives future prompts. However, the integration made the platform feel less closed than I expected.

The generated application still depends on Base44 services and SDKs. Owning the repository is not the same as migrating the entire backend without effort. That is a normal platform trade-off, but it needs to be understood.

The connectors significantly expand the useful range

The integration dashboard was another moment when Base44 started feeling more like a platform than a simple app generator.

The workspace included connectors for services such as Snowflake, Databricks, and Wiz, as well as built-in capabilities for:

• Sending email
• Uploading files
• Extracting structured information from documents
• Invoking an LLM
• Generating images
• Generating video and speech
• Connecting agents to WhatsApp or Telegram

Built-in integrations run through Base44’s managed provider setup, so creators do not need to configure separate API keys for those common operations. Each live call consumes integration credits. Base44 also supports OAuth connectors, backend functions, reusable custom integrations created from OpenAPI specifications, and account-level MCP connections that the builder chat can use while creating applications. This makes the platform flexible, but the flexibility remains opinionated. You can connect a surprising number of services, but you are still building inside a system designed around Base44’s preferred patterns.

Agents make the platform more ambitious

I initially expected Base44 to be an application builder. The presence of agents and Superagents changed that impression. Base44 agents can use application data, tools, connectors, reusable skills, and memory. They can also interact through WhatsApp, Telegram, and other channels. A future Venture Radar agent could work like this:

That turns Base44 from a place where software is created into a place where software can perform work. It also creates additional risk. An agent needs reliable permissions, logs, boundaries, error handling, and approval processes, especially when it modifies records or communicates externally. For a prototype, the built-in capabilities are compelling. For a production agent, I would test failure behavior much more deeply.

Testing and activity monitoring

Base44 also provides an Activity Monitor where developers can inspect requests, responses, status codes, timing, and request bodies in real time. That is important because conversational building becomes frustrating when the platform hides the cause of a failure. The Activity Monitor provides at least one conventional debugging layer beneath the AI interface.

The platform also promotes verification, testing agents, and security checks before publication. These tools help reduce the gap between “the screen looks correct” and “the application actually behaves correctly,” although they do not replace human testing.

Templates and partners are more important than they appear

Base44 includes community templates and private workspace templates. Creators can publish templates for free or sell them, while organizations can preserve reusable internal starting points. The platform also has a partner network connecting users with developers, designers, consultants, freelancers, and agencies familiar with Base44. I find this especially interesting because it acknowledges a reality of no-code and AI-assisted development:

Making an application easier to begin does not make every application easy to finish.

A founder may create the first version independently and then hire an expert for an integration, a security review, a complex workflow, or production preparation.

Base44 does not mediate the contracts or payments; users and partners handle those agreements directly. An ecosystem of specialists and templates could become a meaningful advantage. Features can be copied more easily than a network of people building businesses around a platform.

Then I rebuilt it as a mobile app

After finishing the web experiment, I created another version of Venture Radar from scratch, this time asking Base44 to optimize it as a mobile application. The publishing flow offered two choices: web or mobile.

For mobile, Base44 organized the process into three stages:

1. Check the app.
2. Build the store files.
3. Submit the app.

The process was easier to understand than I expected. The first stage scanned the application against App Store and Google Play guidelines. It then displayed the areas that passed and the issues that still needed improvement. In my case, most checks passed, but the scan warned about unified navigation and the back stack.

Five iterations to reach store readiness

The mobile refinement process required approximately five rounds. Base44 proposed the corrections, but it did not apply every change automatically. I reviewed the suggestions, sent or approved the fix through the builder, and reran the scan.

The platform could then generate the files required for submission and explain the remaining steps in Apple’s and Google’s developer consoles. The documentation confirms that Base44 can scan the app, suggest improvements, and generate store packages while the user remains responsible for their developer accounts and final submission.

I still missed an easier way to test the application directly on my phone before reaching the packaging stage.

The current mobile architecture is also important to understand. Base44 packages the published web application inside a secure native web-view wrapper. That allows many web updates to appear without another store submission, but native-only capabilities such as push notifications and full offline mode are not currently supported.

For dashboards, portals, forms, booking tools, and many business apps, that may be enough. For a product whose main value depends on deep native functionality, background execution, Bluetooth, sensors, or offline-first behavior, it may not be the right architecture.

Where Base44 is genuinely strong

After the test, I think Base44 is particularly strong in four areas. First, it is excellent for idea validation. A founder can move from a written description to something another person can use in less than an hour.

Second, it fits internal software extremely well. Dashboards, portals, approval systems, operational tools, and structured workflows are natural candidates. Third, it becomes especially interesting for website-adjacent applications. This is where the Wix acquisition may eventually create the strongest strategic advantage.

Finally, it is very good for nontechnical and semi-technical creators. Authentication, databases, permissions, hosting, and deployment no longer need to be separate projects before the person can evaluate the idea.

For technical users, the value is different. Base44 removes repetitive setup but still offers code access, GitHub, logs, integrations, backend functions, APIs, and MCP connections.

Where I would be cautious

I would be more cautious with highly specialized infrastructure. An application built around complex AWS services, unusual event-driven systems, custom machine-learning pipelines, advanced networking, or deep cloud-provider integration may eventually fight against the simplicity that makes Base44 attractive.

Base44’s opinionated environment is the source of both its speed and its limits. Scalability and reliability also remain open questions from this experiment. A successful 45-minute build does not prove how the application behaves with thousands of active users, years of data, production incidents, or repeated schema migrations.

AI-based iteration can also introduce regressions. Every prompt may touch more of the project than expected, particularly when modifying data models or cross-cutting business logic. GitHub, version history, testing, security scans, and activity monitoring reduce that risk, but they do not eliminate it.

The Titan thesis

Base44 could become a major platform if generating custom software becomes a normal alternative to buying generic software. Many businesses still adapt important processes to spreadsheets, shared inboxes, forms, and SaaS products that never fit particularly well.

The failure thesis

Base44 could lose differentiation if full-stack application generation becomes a standard feature inside larger development environments.

Authentication, databases, deployment, integrations, and agents are quickly becoming expected features rather than permanent advantages. The platform also needs to remain valuable after the exciting first month. Attracting users who want to generate an app is easier than retaining teams through debugging, maintenance, migrations, security reviews, growth, and production incidents.

Vertical integration may become Base44’s strongest advantage, but it also creates pressure to remain competitive at the model, builder, backend, integration, deployment, and mobile layers.

Small AI Titans scorecard

Final Small AI Titan score: 8.3/10

The score is not a scientific measurement. It is a consistent way to compare the companies covered in this series.

My verdict

I arrived at Base44 because the advertising became difficult to ignore. I stayed because the Wix acquisition made strategic sense and because the platform was more complete than I expected.

In approximately 45 minutes, I generated a private application, added scoring, reviewed user-level permissions, created a Kanban view, changed the data model, added AI-assisted evaluation, connected GitHub, inspected the platform environment, and pushed a second version through its mobile-readiness process.

I used only 15 of the 250 Builder message credits. That does not mean I built a production company in 45 minutes. It means I reached the point where I could test the workflow, understand the product, and put something functional in front of another person.

Base44 does not replace Claude Code, Codex, AWS, or a strong engineering team. I do not think it is trying to. Its value comes from understanding a narrower problem extremely well and removing most of the friction surrounding it. The trade-off is less flexibility. The reward is speed, coherence, and accessibility.

That is why I liked it. In the vibe-coding era, we sometimes evaluate every product as though it must replace every developer and support every possible architecture. Base44 reminded me that this is probably the wrong test.

You do not need to kill a mosquito with a cannon. Sometimes the better product is the one focused enough to solve the actual problem quickly. For that reason, Base44 deserves its position as the first Small AI Titan.

Disclosure

I paid for the Base44 Builder plan used in this experiment. This article is not sponsored by Base44 or Wix, and neither company reviewed or approved the screenshots, measurements, scores, or conclusions.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com, https://medium.com/@crhisto

The biggest AI companies dominate the spotlight, but a new generation of focused products is quietly rising around them.

During the last six months, I have noticed something interesting: Most of the conversations around AI continue to focus on the same companies, products, and announcements. We talk about OpenAI, Anthropic, Google, Microsoft, Meta, Claude Code, Codex, Gemini, and Cursor. A new model is released, a benchmark changes, or one of these companies announces a new feature, and immediately the entire AI community starts discussing it.

This makes sense. These companies are building some of the most important technologies of our time, and what they do affects almost everyone working in AI. But during my day-to-day work, while researching products, testing tools, building prototypes, and trying to understand what is actually useful, I have found many smaller AI companies doing amazing things.

Some are creating applications from a simple description. Others are building infrastructure that allows AI agents to navigate websites. Some are changing how people automate their work, create mobile apps, interact with computers using their voice, or choose between hundreds of AI models. Many of these products have great functionality, real users, and interesting ideas. However, they are not receiving the same level of attention. Sometimes I discover one of them and wonder:

Why is nobody talking about this?

That question gave me the idea for this series. Instead of focusing only on the big fish, I want to explore the smaller AI companies that are building focused products with the potential to become much bigger.

I am calling them Small AI Titans.

Editorial note: This article was written with AI assistance for research organization, editing, and visual ideation. The analysis, opinions, source verification, and final editorial decisions are my own.

There is much more happening beyond the foundation models

It is easy to look at the AI industry and think that most of the opportunity belongs to the companies building the largest models. However, the market is already moving beyond that. According to Menlo Ventures, enterprise spending on generative AI grew from approximately $1.7 billion in 2023 to $11.5 billion in 2024 and $37 billion in 2025. More importantly for this series, around $19 billion of the 2025 total went to the application layer: the products that people and companies use on top of the underlying models.

This is an important distinction. The foundation models get most of the attention, but more than half of enterprise generative-AI spending is already going to applications. These include coding tools, automation platforms, productivity software, healthcare products, sales applications, creative tools, and solutions designed for specific industries or jobs.

Menlo also estimates that 76% of enterprise AI use cases were purchased from vendors in 2025 rather than built completely inside the organization. In 2024, the difference between buying and building was almost equal. This suggests that companies are becoming more willing to adopt specialized AI products when those products solve a real problem and can reach production faster. In other words, the opportunity is not only in creating the next GPT, Claude, or Gemini. There is also a massive opportunity in creating the best product for one particular problem.

AI is also changing who can build a company

The number of people capable of creating and launching software is growing. A 2026 research manuscript in arxiv studying more than 160,000 Product Hunt launches found that entrepreneurial activity increased significantly after the release of ChatGPT, with a particularly strong increase among solo entrepreneurs. The researchers also found an important limitation: lowering the barrier to launching a product does not automatically create better companies, and teams still dominate among the highest-ranked launches.

I think both parts of that conclusion matter: AI makes it easier to start, and it does not make it easy to succeed.

Today, a small team can build an application, create its design, generate content, automate customer support, analyze user behavior, and deploy infrastructure using tools that did not exist a few years ago. But because everyone has access to similar capabilities, differentiation becomes even more important.

The winners will probably not be the companies using the greatest number of AI features. They will be the companies that understand a problem deeply, create a better experience, and find a way to reach the right users. Those are the companies I want to find with this series.

What is a Small AI Titan?

The word small can be confusing. A company does not need to have only five employees or be completely unknown to qualify. Some of the companies I will cover have already raised significant funding. Others have millions of users, large enterprise customers, or strong open-source communities. They are small mainly in comparison with the attention received by the dominant AI companies.

A Small AI Titan is a company or product that:

• Is not yet part of the usual mainstream AI conversation.
• Solves a specific problem in an interesting way.
• Has a product that people can already use or test.
• Shows some evidence of adoption, growth, revenue, funding, or community interest.
• Could potentially become a leader in its category.
• Still has meaningful risks and could also fail.

The last point is important. This series will not assume that every company raising money will become successful. Funding is a signal, but it is not proof of product quality, defensibility, or long-term potential.

Some of these companies may become important platforms. Some may be acquired. Some may be copied by larger companies. Others may disappear when the underlying models improve or when a feature becomes available directly inside ChatGPT, Claude, Gemini, or Microsoft 365. The interesting part is understanding which outcome is more likely — and why.

Some of the companies already on my radar

To make the idea more concrete, these are some of the companies and products I currently consider potential Small AI Titans and may explore in future articles: Base44, Lovable, Rork, OpenRouter, Browser Use, Gumloop, Wispr Flow, and others.

They are not all at the same stage. Some, like Lovable, were relatively small not long ago but have grown quickly and are now becoming major players in their category. Others are still at an earlier stage and are only beginning to gain traction. That difference is part of what makes the series interesting. A Small AI Titan is not defined only by its current size, but by the problem it is solving, the momentum it is building, and its potential to become much more important.

Let’s look at a few examples to make the concept clearer:

Base44

Base44 allows users to create functional applications by describing what they want in natural language. It handles much more than generating a user interface, including parts of the backend, data, authentication, and deployment.

Wix acquired Base44 in June 2025 for approximately $80 million, with additional performance-based payments possible through 2029. What makes the story especially interesting is how quickly the product grew before the acquisition.

The important question is not only whether Base44 can build an application. The bigger question is whether companies will continue buying many small SaaS products or start generating their own internal software for specific needs. Base44 will be the first company analyzed in this series.

Rork

Most AI application builders initially focused on websites and web applications. Rork chose a more specific and technically difficult target: mobile apps.

The platform converts natural-language instructions into iOS and Android applications that can be prepared for distribution through the app stores. In April 2026, Rork announced a $15 million seed round to continue developing its mobile-first platform.

Rork interests me because mobile development still involves many complications that web application builders do not need to solve. Publishing, device testing, native functionality, app-store requirements, and mobile user experience all create additional barriers. A focused company may have an advantage here over more general vibe-coding platforms.

OpenRouter

OpenRouter provides a unified layer through which developers can access and route requests across many AI models. This may sound like infrastructure rather than an exciting application, but model fragmentation creates a real problem. The best model can change depending on the task, price, latency, region, modality, and even the week in which you are building the product.

In May 2026, OpenRouter said its weekly volume had grown from 5 trillion to 25 trillion tokens in just six months. It also reported serving more than 8 million developers across over 400 models and announced a $113 million Series B at a reported valuation of approximately $1.3 billion. Even as I was finishing this post at the end of July 2026, this Small AI Titan was already becoming much less small. Stripe was reportedly in advanced talks to acquire OpenRouter in a deal that could value the company at around $10 billion. The negotiations were not final, but the difference between its May valuation and the reported acquisition price shows how quickly this market can change.

Brex also identified model routing and aggregation as one of the main software trends of spring 2026, based on spending data from more than 35,000 customers. Its analysis argued that value is moving toward companies that make a fragmented model ecosystem easier for users and developers to manage. OpenRouter may no longer be small in usage or funding, but it is still much less visible outside technical AI communities than the companies whose models it provides. That is exactly the type of company that belongs in this series.

How I will evaluate each company

I do not want this to become another series called “10 AI tools you need to try.” There are already many lists like that, and most of them explain a product in a few sentences, repeat its marketing language, and move to the next one. For each Small AI Titan, I want to go deeper. Whenever possible, I will use the product myself, test it with a real use case, and share what worked, what did not, and who I think could benefit from it.

The analysis will try to answer the same questions:

1. What problem does it solve?

Not what the landing page says, but the real user problem.

2. What makes the product different?

This may be its user experience, technology, distribution, focus, data, integrations, community, or understanding of a particular industry.

3. Is there evidence that people actually want it?

I will look for usage, customers, revenue, retention, funding, community activity, or other credible signals. These numbers will not always be available, and when they come directly from the company, I will identify them as company-reported.

4. Who should use it?

A product can be good without being useful for everyone. I want to explain who can benefit from it and in what situations.

5. What could make it a titan?

This is the positive thesis: the reason the company could grow into a category leader.

6. What could make it disappear?

This may include strong competition, weak differentiation, dependence on another provider, high operating costs, privacy concerns, distribution challenges, or the risk of the product eventually becoming just another feature inside a larger platform. When it helps readers understand the product better, I may also include code snippets, technical examples, or links to relevant GitHub repositories.

At the end of each article, I will share my assessment of the company’s product differentiation, adoption, market opportunity, defensibility, and risk of being copied, followed by a final score. The score will not be a scientific measurement. It will simply help me keep the analysis consistent and make it easier to compare companies across the series.

What this series will not be

Small AI Titans is not intended to be a collection of advertisements. None of the companies mentioned are paying me to write about them. I may have a positive opinion about a product, but I also want to discuss what does not work, where the company may be vulnerable, and whether the product is truly better than the alternatives already available.

The series will not focus only on funding announcements. Raising $50 million is an interesting signal, but it does not automatically mean that a company has a great product or a sustainable business. A small bootstrapped startup solving a real problem can be even more interesting. It will not be limited to tools for developers. AI development products are important, but I also want to explore companies working in voice, healthcare, education, creative work, personal productivity, finance, research, e-commerce, and other industries.

Finally, this series will not assume that every company covered will become enormous. The name Small AI Titans represents their potential — not a guaranteed outcome.

Why I am starting this now

The AI industry is moving so quickly that it is difficult to separate meaningful products from temporary experiments. New tools appear every day. Many look impressive in a demonstration but are not reliable enough for real work. Others solve a small but important problem and quietly develop loyal users before most of the market notices them.

I want to pay more attention to the second group. The large AI companies will continue to shape the industry, and I will continue following them. But the foundation models are only one layer of what is being created.

The applications built above them may determine how AI is actually experienced by most people. The next important AI company may not begin by building the smartest general-purpose model. It may begin by solving one narrow problem exceptionally well. That is the idea behind Small AI Titans.

In the first article, I will take a closer look at Base44: what it does, why Wix paid approximately $80 million for it, how it compares with other application builders, and whether products like it could change how companies decide between buying software and creating it themselves.

There are many AI companies growing outside the spotlight. It is time to start looking at them.

Check the blog series here:

• SMALL AI TITANS #01: I Tried Base44 After Seeing It Everywhere. The Interesting Part Wasn’t the First App. Wix paid approximately $80 million for an AI builder that combines apps, backends, workflows, agents, and deployment. I wanted to understand what it could actually change

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com, https://medium.com/@crhisto

The Question After the First Wave of Productivity

For the last several months, we have been using a new generation of AI-assisted and agentic development tools more intensely: Claude Code, Codex, Cursor, GitHub Copilot, Windsurf, Lovable, Bolt, Devin, and Google Antigravity, among others 😱. After seeing how fast something can move from idea to prototype with the right prompts, context, skills, instructions, and constraints, I keep coming back to one uncomfortable question: if GenAI can make so many things easier, what is work about now?

At first, the obvious answer seems to be productivity. Write faster. Code faster. Summarize faster. Build faster. Reduce friction. Save time. Use fewer people. Spend fewer tokens. Optimize everything. But I am starting to think that this is only the surface-level answer. The deeper question is not whether GenAI can help us create more. It can. The deeper question is what we should create, why we should create it, who should be involved, and how we make sure the system we are building does not quietly erase the human part of the work.

Because there is a real risk here. If we are not careful, we will take a technology that could give us more space to think, communicate, collaborate, and rest, and we will use it only to compress more work into the same amount of time. We will save hours, and then immediately fill those hours with more tasks, more meetings, more tickets, more dashboards, more “quick asks,” and more artificial urgency. That would be a sad outcome. GenAI should not only make us faster. It should make us more intentional.

I have actually been thinking and writing around this for months. Not in a single structured sprint, but through scattered notes that came out of meetings, coffees, lunches, conversations with colleagues and friends, and some personal experiences that kept returning to the same question from different angles. Over time, the pattern became clearer to me: the more GenAI makes execution easier, the more human questions move to the center. Not only what we build, but how we work, how we relate to each other, what kind of pressure we normalize, and what kind of culture we are quietly creating while we optimize everything else.

In one of those coffee conversations, a friend and I ended up with a simple idea that stayed with me: maybe the future is not one person alone with ten agents, but the right people in front of a board deciding what those agents should even do. The value is not only in prompting better. It is in thinking better together before the prompting starts.

Put the Tokens Where They Make Sense

One of the most important skills in this new stage is knowing where to spend attention. Not every problem needs an agent. Not every workflow needs a multi-agent architecture. Not every internal tool needs a complex stack, a vector database, a graph, a planner, a memory layer, a RAG pipeline, and five automated evaluators. Sometimes the best solution is a script. Sometimes it is a spreadsheet. Sometimes it is a better conversation. Sometimes it is choosing not to build anything yet.

This is where the old engineering instinct still matters: do not overengineer things. Put the tokens where they make sense. Put the right people in front of the right problem. Use the model when it expands thinking or accelerates responsible execution. Do not use it just because it is available. The temptation now is to automate before understanding, but the better move is still the same as before: understand the problem, understand the people, understand the constraints, and only then decide what should be built.

What Happens to Managers?

This also changes the question of management. A common reaction is to ask what will happen to managers if AI agents can plan, write, summarize, code, test, and report. I do not think the answer is simply that managers disappear. But I do think bad management will become much more visible. If a manager only moves information from one place to another, AI will do that better. If a manager only tracks tasks, generates reports, or asks for status updates, AI will do that faster. If a manager only translates vague pressure from above into vague pressure below, maybe that role deserves to disappear.

But real management is not just task tracking. Real management is context design. It is helping people understand what matters. It is deciding what not to do. It is creating the conditions for good judgment. It is noticing when someone is blocked but afraid to say it. It is making trade-offs explicit. It is protecting a team from noise. It is helping people disagree without destroying trust.

Interestingly, I have also noticed that people who are good with real teams are often better at working with AI agents too. Peter Steinberger, the creator of OpenClaw, has talked about a similar idea: working well with agents is not only about technical skill, but also about knowing how to communicate intent, context, and expectations clearly.

Managing agents requires clarity, context, sequencing, feedback, boundaries, and verification. You need to explain the goal. You need to provide the right background. You need to define what good looks like. You need to review the output. You need to notice when the agent is confidently moving in the wrong direction. In that sense, it is not so different from leading humans, except that with humans you also need empathy, motivation, trust, and respect.

So perhaps the future manager is not only a people manager or a project manager. Perhaps the future manager becomes an orchestrator of humans, agents, context, and accountability. But accountability is the key word. You can delegate execution. You can delegate exploration. You can delegate a first draft. You can delegate a refactor. You can delegate analysis. You cannot fully delegate responsibility.

This is especially important because managers themselves seem to be under pressure. Gallup’s 2026 State of the Global Workplace report found that only 20% of employees worldwide were engaged in 2025, while global manager engagement fell from 31% in 2022 to 22% in 2025. That matters because managers are not just another layer of reporting. They are often the people responsible for translating strategy into reality, protecting teams from chaos, and creating the emotional conditions under which people can do good work.

The irony is that at the exact moment when managers need to become better at context, communication, and culture, many organizations are asking them to do more with less: manage hybrid work, adopt AI, reduce costs, keep teams engaged, explain uncertainty, and still deliver faster. In that world, the manager of the future cannot just be a productivity multiplier. They also need to be a human stabilizer.

The Cast Away Problem

The other day, I watched a video on a social network about the Cast Away movie. At the beginning of the movie, Chuck Noland is obsessed with time, efficiency, and operational performance. Everything is measured. Everything is urgent. Everything exists inside the logic of the system. Then the system collapses. The plane crashes. The company disappears. The calendar disappears. The meetings disappear. The logistics network disappears. The clock loses its old meaning.

On the island, Chuck becomes incredibly productive, but in a completely different way. He learns to survive. He learns to make fire. He learns to use what he has. He learns through failure. He learns what matters when the system is gone. And there is one detail that stayed with me: once he is on the island, he discovers the body of one of the pilots and realizes that the pilot had a name: Albert Miller. Not a function. Not a role. Not just “the pilot.” A person.

That small realization matters. Inside large systems, people can become roles: developer, manager, architect, analyst, product owner, resource, headcount, capacity, FTE. But when the system breaks, the humanity becomes visible again. Maybe that is one of the dangers of extreme optimization. It can hide the person behind the function. It can make us believe that the system is the reality, when the system is only a structure we created to coordinate human effort.

GenAI can make this better or worse. It can help us remove repetitive work so people have more time for thinking, learning, creating, and connecting. Or it can turn everything, including human conversations, into something to be tokenized, summarized, measured, compressed, and optimized. That is the fork in the road.

Inauthentic Work, Acceleration, and the Risk of Becoming the System

This also connects with Martin Heidegger’s idea of inauthentic life: the risk of becoming absorbed by what “one” does, what people expect, what the system rewards, what the calendar demands, and what the company measures. In work, this can look completely normal. We attend meetings because meetings are what people do. We build features because the roadmap says so. We optimize metrics because the dashboard is watching. We answer immediately because responsiveness has been confused with value. We keep moving because stopping would force us to ask whether the direction still makes sense.

Byung-Chul Han’s The Burnout Society adds another useful layer. Today, pressure does not always arrive as “you must.” Very often, it arrives as “you can.” You can do more. You can optimize more. You can answer one more message, ship one more feature, run one more experiment, or ask one more model. That is what makes the productivity trap so subtle: it can feel like freedom while behaving like pressure.

GenAI can intensify this if every saved hour becomes an excuse to raise expectations again. The system gets faster, but the person inside the system does not necessarily become freer. That is the fork in the road. GenAI can amplify inauthentic work through more output, more dashboards, more synthetic urgency, and more work about work. Or it can give us time back.

And that time should not automatically become more tasks. Some of it should become better thinking, better conversations, better rest, better judgment, better relationships, better taste, and better questions. Because if machines help us produce more, the human advantage may be deciding what deserves to exist, what deserves to stop, and what kind of life and culture our work should support.

Burnout, Time, and the New Generation Question

One of the reasons this matters so much is that the efficiency story is colliding with a burnout story. We have better tools, faster systems, and more automation, but that does not automatically mean people feel better at work. In many cases, it only means the same amount of human anxiety can now move faster.

Burnout is not an abstract concept. Gallup has reported that employees who frequently experience burnout are 63% more likely to take a sick day, 2.6 times as likely to leave their current employer, and 13% less confident in their performance. That is not just a personal problem. It is a signal that the system is consuming the people who make the system work.

This is where the conversation about time becomes more interesting. Younger generations are not only reacting to salary or title. They are reacting to the way life feels. Deloitte’s 2026 Gen Z and Millennial Survey found that only 6% of Gen Zs and millennials say achieving a leadership position is their primary career goal. Only 25% of Gen Zs and 21% of millennials prefer fast-paced career progression marked by rapid promotions. That does not mean they lack ambition. It means many of them are asking a different question: what is a career for, if it destroys the person who is building it?

At the same time, this is also the first generation entering adulthood and work in a world where digital attention is already fragmented by default. Time is not only scheduled now; it is competed for. Platforms, notifications, chats, feeds, side conversations, and constant online presence all fight for the same cognitive space that real work, rest, and reflection need. Ofcom’s 2025 Online Nation report found that UK adults spent an average of 4 hours and 30 minutes online per day, while 18–24-year-olds averaged 6 hours and 20 minutes. That is not automatically good or bad, but it does remind us that attention has become one of the most contested resources in modern life.

So when we talk about productivity, we should not pretend that the real scarcity is only labor. The real scarcity is clean attention. It is the ability to think without being constantly interrupted, measured, redirected, summarized, or optimized. This is why burnout becomes such an important signal. It is not just a health issue or an HR issue. It is also an organizational design issue. Burnout often reveals that the system is asking for output without protecting attention, energy, or meaning.

And if GenAI simply helps companies extract more output from already fragmented people, then it will not solve the problem. It will accelerate it.

Ideation Becomes the Bottleneck

I used to think the hard part was creating. Now I am less sure. With the right tools, creating a first version of something is easier than ever. A prototype, a landing page, a data pipeline, a small internal application, a draft, a design, a script, a test suite: all of these are becoming faster. That does not mean they are automatically good. It means the bottleneck is moving.

The bottleneck is not always “can we build it?” The bottleneck is increasingly “is this the right thing to build?” And that question is harder. Good ideation is not just having ideas. It is testing assumptions. It is bringing different perspectives into the room. It is letting someone challenge your first thought. It is listening carefully enough to notice the part of the problem you were missing.

This is why I do not believe the future of work is one person alone with ten agents doing everything. That will happen sometimes, and for some people it will be powerful. But in general, ideation with multiple people is richer than ideation alone. The point is not to have more people in every meeting. The point is to have the right people thinking together about the right problem.

A good project may increasingly look like a small group of thoughtful people in front of a board, physical or virtual, discussing the problem, the context, the user, the constraints, the risks, and the simplest responsible path forward. Then AI helps them explore options, generate alternatives, challenge assumptions, create prototypes, document decisions, and accelerate execution. But the quality of the result still depends on the quality of the thinking. And the quality of the thinking still depends on the quality of the conversation.

Communication Is Becoming a Technical Skill

This is why I think communication becomes more important, not less. Listening becomes a technical skill. Giving feedback becomes a technical skill. Saying “I think this is wrong” without attacking the person becomes a technical skill. Admitting “I was wrong” becomes a technical skill. Creating psychological safety becomes a technical skill. Knowing when to stop, rest, and come back with a better mind becomes a technical skill.

These things used to be called soft skills, but that name feels wrong now. In an AI-assisted world, they become hard requirements. They determine whether the team can think clearly, whether the agents are directed correctly, whether the solution is aligned with reality, and whether people still want to work together after the project is done. The future of development may be less about typing every line of code and more about directing multiple streams of execution responsibly. But directing execution responsibly requires more humanity, not less.

Culture Is the Real Operating System

This is also why I think culture is becoming even more important than before. In many companies, culture is still treated like a soft layer: values on a slide, a few rituals, some words repeated in all-hands meetings. But culture is not decoration. Culture is the operating system behind the visible work. It shapes what people are rewarded for, what they are afraid to say, how conflict happens, whether people can disagree safely, whether managers protect context or generate noise, and whether speed is used intelligently or blindly.

And culture, by itself, is not automatically good. A company can have a very strong culture and still be deeply unhealthy. It can have a culture of urgency, fear, over-measurement, political silence, or constant performative productivity. It can also have a culture of trust, clarity, thoughtful debate, responsibility, and sustainable execution. The point is not whether a culture exists. Every company has one. The real question is what kind of culture is being built, reinforced, and tolerated every day.

That is why leaders now have a more important responsibility than just setting targets or approving strategy. They need to lead the discussion about culture directly. They need to be explicit about what kind of team they are trying to build, what behaviors they want to normalize, what tradeoffs they are willing to reject, and how AI should fit into that culture. Because if leaders do not define that discussion deliberately, the culture will still form on its own, only then it will be shaped by habit, pressure, ambiguity, and whatever gets rewarded in the short term.

In that sense, AI does not reduce the importance of culture. It increases it. When execution becomes cheaper, culture becomes more visible. When information moves faster, tone matters more. When agents can do more work, the human environment surrounding that work becomes more decisive. The companies that will benefit most from GenAI may not be the ones that automate the most, but the ones that know how to combine automation, judgment, respect, and healthy human coordination in a coherent way.

Two Types of AI-Native Companies

I can imagine two types of companies emerging. The first type will use GenAI to maximize human potential. These companies will automate repetitive work, reduce unnecessary meetings, improve documentation, support better decisions, and give people more space for deep collaboration. They will understand that the value of saved time is not only more output, but better input: clearer thinking, better judgment, and stronger teams.

The second type will use GenAI to maximize extraction. These companies will tokenize every conversation, summarize every interaction, measure every movement, automate every pause, and treat human beings as another component in the machine. They will save time only to demand more time. They will increase productivity and somehow also increase burnout.

Both will call themselves AI-native. But they will not be the same. One will use AI to make work more human. The other will use AI to make humans more machine-like.

This may be the cultural divide that matters most. Not whether a company uses GenAI, because almost every company will. The real question is what kind of culture forms around that use. Does AI create more agency or more surveillance? Does it give people more room to think or less? Does it improve collaboration or simply make pressure more efficient? Does it help managers become better leaders, or does it turn them into operators of a more automated control system?

So, What Are We For Now?

So, if GenAI can make almost everything, what are we for now? Maybe we are here to decide what should be made. Maybe we are here to bring judgment, taste, ethics, responsibility, and context. Maybe we are here to create the conversations that make better ideas possible. Maybe we are here to make sure that when systems become more powerful, they do not hide the people inside them.

And maybe the real opportunity is not to become endlessly productive, but to become effective without becoming fried. Because being effective and being rested are not opposites. They are partners. A rested mind has better ideas. A good conversation can save weeks of execution. A clear problem statement can save thousands of tokens. A small team with trust can outperform a large system full of noise.

GenAI can help us build faster. But perhaps the best use of the time it saves is not to build more. Perhaps the best use is to become better at being human together.

Maybe one of the biggest questions for the AI era is not only what we will automate, but what kind of culture we will build around that automation. Because culture decides whether saved time becomes better thinking or just more pressure. It decides whether AI becomes a tool for human expansion or a tool for human compression.

And maybe that is why this conversation feels so important to me now. The future of work is not only being coded. It is also being normalized in meetings, in expectations, in feedback, in silence, in what leaders praise, and in what teams quietly learn to endure.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com/, https://medium.com/@crhisto

A long time ago, at the beginning of my journey as a software engineer, I learned about rubber duck debugging. The idea is simple: when you are stuck, you explain your code or your problem step by step to a rubber duck. The duck does not answer. It does not judge. It does not interrupt. It simply listens. And somehow, that is often enough.

By forcing yourself to explain the problem clearly, you start noticing the gaps in your own thinking. You discover assumptions. You find contradictions. You realize that the bug was not always hidden in the code, but sometimes in the way you were understanding the problem. That was the part that fascinated me from the beginning: the duck was not solving anything, but the conversation with it was changing the way I understood the problem.

I loved the idea so much that, over time, I accidentally became the kind of person who buys rubber ducks in different countries. Some people collect magnets. Some people collect postcards. I collect ducks. Different colors, different costumes, different countries, different personalities. A small army of silent debugging assistants.

At some point, I even started using the idea outside programming. When I had to think through a decision, an architecture, a research idea, or even a personal problem, I would explain it out loud or write it down as if I were talking to one of my ducks. Sometimes the “duck” was an actual person, but there was one rule: the person was only allowed to ask simple questions like “Why?”, “What?”, “When?”, or “How?” Those small questions are surprisingly powerful. They force clarity, expose weak arguments, and make you slow down enough to notice what you were avoiding.

But now we are in the GenAI era. ChatGPT, Claude, Gemini, and other models can read code, explain errors, generate alternatives, challenge assumptions, and even propose fixes. In agentic systems, AI can go even further: it can use tools, inspect logs, execute workflows, and act on our behalf. So I started wondering:

Did AI fire my ducks?

When the duck talks back

At first, it is tempting to say yes. The classic rubber duck was silent. The AI duck answers. The classic rubber duck helped us think by listening. The AI duck helps us think by questioning, explaining, comparing, and sometimes disagreeing. But after using GenAI for a while, I do not think the duck lost its job.

I think the duck got promoted.

The real value of rubber duck debugging was never the plastic duck. The value was the process: slowing down, explaining clearly, exposing assumptions, and finding contradictions in your own mental model. GenAI does not replace that process. It amplifies it, but only if we use it intentionally.

That distinction matters because AI can easily become an answer machine. You ask, it responds, you copy, and you move on. That may be useful when the task is simple, but it is dangerous when the goal is learning. If we only use AI to get final answers, we may become faster, but we may also become weaker at understanding how those answers were produced.

The danger of easy answers

One of the biggest risks of AI is that it can make us intellectually lazy. If we only ask for the final answer, we may get the task done faster, but we may also learn less. That matters because in modern software engineering, and especially in AI systems, the hard part is often not writing the code. The hard part is understanding the system.

Why did the agent choose that tool? Why did the retrieval step return the wrong context? Why did the model hallucinate? Why did the workflow fail silently? Why did the architecture work in a demo but not in production? These questions are not solved only by asking for “the fix.” They require understanding the assumptions, the flow of information, the failure modes, and the gap between what we think the system is doing and what it is actually doing.

In the GenAI era, the value of the engineer is not only in manually producing every artifact. It is increasingly in knowing how to think, how to ask, how to evaluate, and how to guide intelligent systems. That means our prompts should not only ask AI to solve the problem. They should ask AI to help us think better.

Over time, I stopped asking AI only for answers and started asking it to help me inspect my own reasoning. These are some of the prompt patterns I now use.

I know the idea of using AI as a rubber duck is not new. Many developers already use ChatGPT, Claude, or other assistants to explain errors and reason through code. But I think the more interesting shift is not debugging itself. It is learning. The real opportunity is to use GenAI not only to find the answer, but to improve the way we think our way toward the answer.

Here are four prompt patterns I use depending on whether I want to debug a problem, learn a concept, or reason about an AI system.

My new Rubber Duck Debugging prompt

When I am stuck with a problem and want to avoid jumping too quickly to a solution, I use a prompt like this:

Use a Rubber Duck Debugging approach.

Do not jump directly to the solution.

First:
1. Restate the problem in simple terms.
2. Explain what should be happening.
3. Explain what is actually happening.
4. List the assumptions.
5. Identify possible failure points.
6. Ask clarifying questions if needed.
7. Only then propose solutions ordered by probability.

This changes the interaction. Instead of treating the model as an answer machine, I treat it as a thinking partner. The goal is not only to fix the issue. The goal is to understand the issue. And that distinction matters because sometimes the fastest answer is not the most useful one. Sometimes what we need is not a fix, but a better mental model of what is happening.

This is very close to the original spirit of rubber duck debugging. The difference is that the duck can now talk back. It can ask questions, challenge the sequence of events, identify assumptions, and help you separate what you know from what you are guessing. Used well, the model does not replace the thinking process. It makes that process more explicit.

Rubber Duck Debugging for learning

I also use a variation when I want to learn something deeply. This is especially useful when I am studying architectures, debugging complex systems, reviewing technical decisions, reading papers, or trying to understand a new concept. In those cases, I do not want only a short answer. I want the model to help me improve the way I reason about similar problems in the future.

My goal is not only to get the answer.
My goal is to improve my thinking.

Therefore:
- explain the reasoning
- teach the mental models
- connect the answer to first principles
- highlight tradeoffs
- expose hidden assumptions
- mention common mistakes
- explain how an experienced engineer would think about this
- generalize the lesson beyond this example

Prefer insight over speed.

This prompt is useful because it changes the objective. Without this instruction, AI often optimizes for completion. It gives you the answer and moves on. But when you explicitly ask for learning, the interaction becomes different. The model starts explaining not only what to do, but why it matters, what assumptions are involved, what tradeoffs exist, and how to generalize the idea.

That is where the real value appears. Not just in getting something done, but in becoming better at understanding similar problems in the future. The important part is this: do not optimize only for the output. Optimize for the learning process.

Rubber Duck Debugging for AI and agentic systems

For GenAI and agentic systems, I usually make the prompt more specific because AI systems fail in strange ways. The issue is not always the model. Sometimes it is the prompt. Sometimes it is the retrieval layer. Sometimes it is memory. Sometimes it is tool selection. Sometimes it is orchestration. Sometimes it is a missing evaluation framework. Sometimes it is a silent failure hidden behind a beautiful demo.

For this kind of problem, I use something like this:

Use Rubber Duck Debugging focused on AI systems.

As you analyze:
- trace the system step by step
- identify where orchestration complexity appears
- explain what each component assumes
- highlight scalability and reliability risks
- identify observability gaps
- explain how this pattern appears in production AI systems

At the end provide:
- architecture lessons
- anti-patterns
- production considerations
- debugging signals
- how senior engineers reason about this class of problem

A good AI rubber duck does not only say, “Here is the fix.” It asks better questions. What assumption are we making? What evidence do we have? What would disprove this hypothesis? Where could the system be failing silently? What would a senior engineer inspect first?

That is where the learning happens. And in AI systems, that kind of thinking is essential because the most dangerous bugs are not always exceptions, crashes, or failed deployments. Sometimes the most dangerous bugs are hidden assumptions that continue working just well enough to look correct.

Rubber Duck Debugging for certification study

Since I am kind of a fan of AWS certifications — as I wrote in my post about getting 13 AWS certifications in 13 months and 13 days — I also use this approach a lot when studying for exams. When I get a practice question wrong, I do not only ask the model for the correct answer. I ask it to help me understand why my answer looked correct to me. That is where the real learning happens. Many certification mistakes are not about completely missing the topic, but about overlooking a constraint, confusing two similar services, or applying the right concept to the wrong scenario.

Use Rubber Duck Debugging to help me learn from this certification question.

I will give you:
- the question
- the options
- my selected answer
- the correct answer

Help me understand:
1. What the question is really asking.
2. Why my answer looked attractive.
3. Why my answer is wrong.
4. Why the correct answer is better.
5. What concept or tradeoff I misunderstood.
6. What mental model I should remember next time.

This turns every wrong answer into a learning opportunity. Instead of only memorizing that one option was correct, I can debug the reasoning that led me to the wrong choice. In AWS exams, that is especially useful because many questions are built around tradeoffs: cost versus performance, availability versus durability, serverless versus managed infrastructure, or object storage versus file storage. The AI rubber duck helps me find the weak spot in my intuition and strengthen it for the next question.

From debugging code to debugging thinking

This is the part that interests me the most. Rubber duck debugging started as a technique for debugging code, but in practice, it is much broader than that. It is a technique for debugging thought.

When you explain something clearly, you test whether you actually understand it. When you ask “why?” several times, you find the weak points in your reasoning. When you describe what should happen and what is actually happening, you expose the gap between your model of the world and reality.

GenAI can make this process much stronger, but only if we ask it to. If we use AI only as a machine that gives answers, we may become faster but less thoughtful. If we use AI as a partner that helps us question, reason, compare, and reflect, we can become faster and more capable.

That is why I think the future of AI-assisted learning is not just about better models. It is about better conversations.

So, did AI replace the duck?

Not really. The duck was never truly about the duck. It was about making our thinking visible. GenAI gives us a new version of the same idea: a duck that can talk back, ask better questions, challenge our assumptions, and help us build stronger mental models.

But the responsibility is still ours. If we use AI only to get answers, we may become faster, but also weaker. If we use AI to improve the way we think, we can become both faster and stronger. The future of learning with AI is not about outsourcing our brain; it is about building better conversations with it.

So no, my ducks are not unemployed. They have simply been promoted to the board.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com/, https://medium.com/@crhisto

Over the past few months, since the launch of OpenClaw, I’ve found myself going down a bit of a rabbit hole. What started as simple curiosity — “let me try this new agent framework” — quickly turned into something deeper. I began experimenting, breaking things, rebuilding them, and slowly understanding what makes this approach to agents different. Along the way, I started documenting those learnings.

In my first post, We Built Agents That Think. OpenClaw Builds Agents That Act, I explored how OpenClaw breaks the traditional paradigm. Instead of treating agents as something you invoke, OpenClaw behaves more like a system that is always running — observing, deciding, and acting. That shift alone changes how you think about building with LLMs.

After that, I realized something else: the ecosystem was already fragmenting. Different variants were emerging — NanoClaw, PicoClaw, TinyClaw — each with different trade-offs around security, simplicity, performance, and extensibility. That led me to write Which Claw Is Best? A Guide to OpenClaw and Its Variants, where I explored how those differences matter depending on your use case.

But after spending more time actually using OpenClaw (and especially NanoClaw in more constrained environments), a more practical question kept coming up.

What is the right model to put behind this?

Because at the end of the day, the Claw is just the body. The real intelligence — the brain — comes from the LLM you choose. And that’s where things get messy.

There are more options than ever: frontier models with incredible reasoning power (and cost), local models that give you privacy and control, cheaper high-throughput models that are “good enough” for most tasks, and hybrid setups that combine all of the above.

Most existing guides talk about how to deploy OpenClaw, or how to run local models, or how to connect custom providers. But very few answer the question that actually matters when you’re building something real: which model should handle which task — and why?

This post is my attempt to answer that. I’ll break down frontier vs. local models, summarize pricing and context windows, outline hardware considerations, show how to configure multiple models within the same setup, and — most importantly — share when it makes sense to use each type of model in practice.

If the first post was about what OpenClaw is, and the second was about which version to use, this one is about something even more fundamental: what should power it.

Frontier Models: Pricing, Context and Capabilities

Frontier (cloud) models generally deliver state‑of‑the‑art reasoning, coding and tool‑use capabilities with minimal setup but incur per‑token fees and depend on third‑party infrastructure. The table below summarises popular models and their April 2026 prices. Prices are per million tokens (input/output). “Context” refers to the maximum input length the model accepts; some providers offer extended contexts at a higher price.

Quick Picks

- Cheapest: Grok 4.1 Fast
- Best reasoning: GPT-5.4 / Claude Opus
- Best long context: Grok / Gemini
- Best balance: GPT-4o

2026 Frontier Model Updates

Several providers released new models in early 2026. OpenAI’s GPT‑5.4 extends GPT‑4o with stronger reasoning and offers both a 272k context and a 1.05M context tier; the latter costs about twice as much and a Pro tier exists for enterprise workloads. Google’s Gemini 3.1 Pro and 2.5 Pro deliver up to 1M context at moderate prices (roughly $2/$12 and $1.25/$10 per million tokens) and prioritise long‑context summarisation and multilingual support. Anthropic’s Claude Haiku 4.5 is a lightweight 200k‑context model priced at $1/$5 per million tokens; it trades deep reasoning for speed and throughput. These new offerings provide more options across the cost‑performance spectrum.

Observations

Across providers there is a clear cost‑quality trade‑off: models like GPT‑4o, GPT‑5.4 and Claude Opus provide top‑tier reasoning and coding, but cheaper options such as Cohere Command R or Grok 4.1 Fast deliver adequate performance at a tenth of the price. Context windows vary widely — from 128k up to 2M tokens — and longer contexts often cost more and respond more slowly. Finally, some providers offer batch or discounted pricing for asynchronous jobs, which can halve costs when latency is not critical.

April 2026 update: Claude subscriptions no longer cover OpenClaw

As of April 4, 2026, Anthropic disabled the use of Claude Pro/Max subscription quotas in third‑party tools like OpenClaw and NanoClaw. Users must now pay per token or buy extra usage bundles to run Claude models. Anthropic offered a one‑time credit and discounted bundles to ease the transition. The change stems from the high compute demands of agentic workflows and marks the end of “all‑you‑can‑eat” subscription abuse. For Claw users, Claude remains available via API but is now a premium option; hybrid routing and alternative models are therefore even more important.

Emerging Local & Open Models (2026)

Open‑source and locally deployable models have also advanced. The table below summarises notable newcomers. These models can be hosted via Ollama, vLLM or similar back‑ends and are appealing for privacy‑sensitive or offline deployments.

As with frontier models, these open models differ in memory requirements and performance. Gemma 4’s MoE variant offers long‑context reasoning on consumer GPUs; Qwen 3’s models provide multilingual support and adjustable reasoning depth; and GPT‑OSS‑20B is ideal for code‑heavy workloads on modest hardware.

Hardware Considerations for Local Models

Running large models locally still requires substantial VRAM. Entry‑level GPUs (3–4 GB VRAM) can only run 3–4B models; mid‑range cards (6–8 GB) support 7–9B models; high‑end cards (10–12 GB) handle 12–14B models; and 16–24 GB is needed for 22–35B models (see detailed hardware breakdown here). Workstation‑class GPUs with 48 GB VRAM or multiple cards are required for 70B+ models like Llama 3.3 70B. Model context windows consume memory; quantization can reduce requirements at the cost of accuracy.

Cost of Self‑Hosting

Self‑hosting eliminates per‑token fees but requires upfront hardware investment and electricity. A mid‑range Mac Studio or Linux server with a high‑end GPU typically amortises its cost after roughly a year of heavy usage, while lightweight deployments on Raspberry Pi break even in weeks. Once hardware is paid off, local LLM use costs almost nothing.

Strengths and Limits of Local Models

Local models offer full data privacy, zero per‑token cost and offline operation. Many run at 30–80 tokens per second on consumer GPUs and support long contexts up to 256k tokens. However, they still trail frontier models in complex reasoning and multi‑file code generation, and hardware constraints limit the maximum context window and model size. For high‑stakes or deeply analytical tasks, frontier models remain superior.

When to Use Local vs. Frontier Models

A pragmatic guideline is “personal data goes local; everything else depends on cost and quality.” Local deployment ensures 100 % data privacy and zero per‑token fees but demands significant VRAM, whereas cloud APIs add network latency and recurring costs. Rather than memorising individual pairings, think in terms of task complexity and hardware budget:

• Low‑risk, high‑volume tasks (email triage, summarisation, quick drafts) are ideal for open models like Gemma 4, Qwen 3 or GPT‑OSS‑20B. These models run on consumer GPUs, support long contexts and cost nothing per token.
• Moderate tasks (code generation, chat responses, medium‑length documents) can leverage mid‑range frontier models such as Gemini 3 Flash, Mistral Large 2 or Cohere Command R. They offer reasonable quality at lower prices than Claude or GPT‑5.4.
• High‑stakes reasoning, coding or strategic planning should be routed to premium frontier models like GPT‑5.4, Claude Opus, Claude Sonnet or Mistral Large 2. These models excel at complex analysis but cost more and may require API access.

A hybrid strategy — using local models for everyday and privacy‑sensitive tasks and escalating to frontier models only when needed — offers the best balance of privacy, cost and performance. In practice, this means configuring your Claw with a cheap local model as the primary handler and one or two frontier models as fallbacks. Such routing can reduce API bills by 60–90 % while preserving quality.

How to Choose the Right Model (Simple Framework)

If you don’t want to overthink it, use this:

• Is the task sensitive or private?
  → Use a local model
• Is it high-volume or cost-sensitive?
  → Use Grok 4.1 Fast / Gemini Flash / Command R
• Is it complex reasoning or coding?
  → Use GPT-5 / Claude Opus
• Not sure?
  → Start with local, then escalate to frontier

Configuring Multiple Models in OpenClaw/NanoClaw

OpenClaw supports multiple providers through gateways like LiteLLM or OpenRouter. A recommended stack from AiOps School uses a primary model (e.g., OpenAI), coding fallback (Claude Sonnet) and cheap background model (Mistral or Qwen) routed via LiteLLM. The configuration file in your Claw can specify several models with different contextWindow and reasoning settings; for instance, the Haimaker article shows an openclaw.json where Qwen 3.5 27B handles default tasks (reasoning: false to disable chain‑of‑thought for speed) while Claude Sonnet acts as a fallback for complex reasoning. Such routing can be extended: use Qwen for summarisation, Mistral for cheap generation, and Claude Opus for high‑precision tasks, all within the same agent.

Bedrock integration is another option. Bedrock exposes multiple models (Claude Sonnet/Opus, Mistral, Llama 3.1 70B, Cohere Command R+) behind a single AWS API and matches provider pricing. This makes it easy to switch models without altering your Claw logic and supports enterprise features like IAM. Note that Bedrock may lag behind direct APIs in releasing new model versions, and some features (knowledge bases, RAG, caching) incur additional charges.

Example hybrid configuration

Below is a simplified openclaw.json snippet demonstrating a hybrid setup using a local model (Gemma 4) as the primary handler with two frontier fallbacks—OpenAI’s GPT‑5.4 (long context) and Anthropic’s Claude Opus. In practice you would also include API keys and provider‑specific settings, but this illustrates the concept:

{
  "model": {
    "primary": "gemma-4-31b",
    "fallbacks": ["gpt-5.4-long", "claude-opus-4.6"]
  },
  "models": {
    "gemma-4-31b": {
      "provider": "ollama",
      "contextWindow": 256000,
      "reasoning": false
    },
    "gpt-5.4-long": {
      "provider": "openai",
      "contextWindow": 1050000,
      "reasoning": true
    },
    "claude-opus-4.6": {
      "provider": "anthropic",
      "contextWindow": 200000,
      "reasoning": true
    }
  }
}

This configuration tells OpenClaw to attempt tasks with the local Gemma 4 model first (fast and free), use GPT‑5.4 long for tasks requiring extended context or deeper reasoning, and fall back to Claude Opus when high‑precision responses are needed. You can add more fallbacks or route specific skills to particular models.

Using gateways with NanoClaw

NanoClaw ships with Claude as its only built‑in model, but you can still call other providers via gateways. For example, set environment variables to route all agent calls through LiteLLM with a provider alias:

export ANTHROPIC_BASE_URL=https://api.anthropic.com
export ANTHROPIC_MODEL=claude-4.6-sonnet
export LITELLMM_MODEL_MAP="{ 'grok-fast':'grok-4.1-fast', 'gpt-5.4':'gpt-5.4-long' }"
export LITELLMM_API_KEY=<your-liteLLM-key>

This instructs NanoClaw to use Anthropic’s API for Claude calls and route any tasks labelled grok-fast or gpt-5.4 through LiteLLM to xAI or OpenAI. Gateway variables allow you to overcome built‑in limitations without modifying NanoClaw’s code.

Model Compatibility Across Claw Variants

Most discussions about model selection assume you are using OpenClaw. In reality, an entire family of Claw variants has sprung up — each with different runtime languages, levels of security and LLM back‑end support. These differences matter when deciding how to route tasks and which models to run. For example, OpenClaw uses a modular architecture that supports Anthropic, OpenAI and local models, while NanoClaw is built on Anthropic’s Agent SDK and only exposes Claude via conversation‑driven configuration. ZeroClaw goes in the other direction: its trait‑driven Rust architecture abstracts providers and supports more than twenty LLM back‑ends. Moltis adds enterprise features and long‑term memory with optional local LLMs, and NemoClaw packages OpenClaw inside NVIDIA’s secure OpenShell along with Nemotron models. The table below summarises the top variants.

Insights

Despite their differences, some common patterns emerge. Provider flexibility ranges from broad (OpenClaw and ZeroClaw) to narrow (NanoClaw is tied to Claude; NemoClaw bundles NVIDIA models). Security vs performance varies too: NanoClaw and NemoClaw emphasise isolation, whereas ZeroClaw and Moltis favour performance and enterprise features. Crucially, hybrid routing remains possible in all variants via gateways (LiteLLM, OpenRouter), allowing you to offload complex tasks to a different provider even when the core framework is restrictive.

Conclusion & Recommendations

Selecting the right LLM for your Claw involves balancing cost, capability, context, latency, privacy and hardware limits. The April 2026 deprecation of Claude subscription quotas means you must now pay per token when using Anthropic models with third‑party agents. This makes premium frontier models like Claude Opus, Claude Sonnet and GPT‑5.4 costlier and underscores the value of cheaper options.

The question is no longer: “Which model is best?”

The real question is: “Which model should handle THIS task?”

The ecosystem now spans three tiers:

• Premium frontier models (GPT‑5.4, Claude Opus/Sonnet, Mistral Large 2) for high‑stakes reasoning and code generation. They command higher rates but deliver the best results.
• Affordable frontier models (Grok 4.1 Fast, Gemini 3/2.5 Pro, Cohere Command R, Mistral, Claude Haiku 4.5), which offer respectable performance at a fraction of the cost. Use them for moderate tasks and long‑context summarisation.
• Open/local models (Gemma 4, Qwen 3, GPT‑OSS‑20B, Llama 3.3, MiniMax M2.5) that run on consumer hardware, provide full data sovereignty and zero per‑token fees. They excel at high‑volume summarisation and casual conversations but may struggle with nuanced reasoning.

The optimal approach is hybrid routing: use a local or inexpensive model for routine and privacy‑sensitive tasks and fall back to premium models only when necessary. Tools like LiteLLM and OpenRouter make this easy by letting you specify primary models and fallbacks in your configuration. Variants like ZeroClaw and Moltis offer even more flexibility by abstracting providers at the runtime level.

Looking ahead, dynamic routing that factors latency, cost and quality could further improve efficiency, and open‑weight reasoning models like GPT‑OSS‑120B may soon close the gap with frontier models. Stay up‑to‑date on pricing and model releases to keep your Claw powerful and economical.

If you’re building with OpenClaw or experimenting with hybrid LLM setups, I’d love to hear how you’re approaching model selection.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com/, https://medium.com/@crhisto

The first thing to say about the AWS Golden Jacket is the obvious one: it is not subtle.

It is bright. Very bright. Let’s address the elephant in the room from the beginning. In pure fashion terms, the jacket may not be the strongest piece in your wardrobe. But that is also completely beside the point.

Because the AWS Golden Jacket is not valuable for its color, its shine, or even the fact that it is physical swag. It matters because of what it represents: discipline, breadth, consistency, and a serious commitment to understanding the AWS ecosystem well enough to solve real problems with the right tools.

And that last part matters.

Too many people reduce certifications to badges, logos, or LinkedIn decoration. But the real value of the journey is not “collecting” exams. It is learning how to think more clearly about architecture, trade-offs, security, operations, data, networking, AI, and cost. It is learning not to kill a fly with a bazooka.

That, to me, is the real meaning of the Golden Jacket.

My journey to the jacket

As I wrote in a previous post, it took 13 certifications in 13 months and 13 days — and then a few extra months of patiently waiting for the physical jacket to catch up.

It was intense, sometimes exhausting, and definitely not linear. Some exams felt aligned with my day-to-day work. Others pushed me into areas where I had to slow down, study more deeply, and accept that passing a test is not the same as mastering a domain.

After I completed all the active AWS certifications, the next step was getting the physical jacket. In my case, that happened through the AWS representative assigned to the company I worked for, which was an AWS Premier Partner. A few colleagues and I were added to a queue, and after roughly three months we got confirmation. Once the shipping details were verified through the updated process, the jacket arrived in the US in just a few business days.

That process can vary. Recent AWS event pages show Golden Jacket programs tied to holding all active AWS certifications, staying current, and applying through an event-specific form or recognition path rather than through a single universal public workflow (like re:Invent2025). At recent AWS event pages, AWS described the Golden Jacket as recognition for professionals who hold all active AWS certifications, and some event programs required all 12 certifications to remain valid during the event.

I also learned something else important: the jacket is real, but the journey should never be about the jacket alone.

Also, for the record: the AWS Golden Jacket was not always waterproof, but now it is!!!.

What the jacket officially gives you — and what it does not

Let’s be honest about this, because the mystique around the Golden Jacket sometimes creates the wrong expectations.

As far as AWS publicly documents, AWS Certification benefits include things like digital badges, a 50% exam discount for a future exam, and event recognition such as access to AWS Certification lounges at re:Invent and select summits. AWS also publicly runs some event-based Golden Jacket application and distribution programs.

But the jacket itself is not a magical VIP pass.

In practice, I have not seen it come with official promises such as:

• priority access to sessions
• guaranteed invites to private events
• discounts or perks by default
• skip-the-line privileges

What it does create is something more organic, and in some ways more useful:

Instant recognition

At AWS events, people notice it immediately. You do not have to explain as much. It becomes a visual shorthand for “this person has gone deep.”

Easier networking

The quality of conversations changes. People approach you differently. AWS folks, architects, builders, partners, and other certified professionals often start the conversation at a more advanced level.

Faster technical trust

The jacket does not prove that every idea you have is correct. But it does signal that you have done serious work across the AWS landscape. That often helps you get to the real conversation faster.

Visibility and personal brand

Whether we like it or not, symbols matter. The jacket is memorable. It stands out in pictures, at events, and on social media. If you are already writing, speaking, mentoring, or building publicly, it amplifies that signal.

Community signal

To people who know what it takes, the jacket says something simple: this person committed to learning broadly and kept going.

That is why I believe the Golden Jacket has real value even without official perks.

Why it is useful to pursue the Golden Jacket

This is probably the most important part of the entire blog post. I don’t believe the value lies in “having all the certifications” as an end in itself.
The real value is becoming more confident in the solution space.

AWS is enormous. The certification journey forces you to build a broader mental map of what exists, what problems each service solves, and what trade-offs come with each decision. AWS organizes certifications across Foundational, Associate, Professional, and Specialty levels, which naturally mirrors the layered understanding required in real-world projects.

That breadth matters because real architecture is rarely about a single service. It’s about combining the right services in the right way — without overengineering.

For me, this was especially important. I come from a strong software architecture background, but one of my main focus areas is machine learning. I wanted to feel confident not only with ML-specific services, but with the entire supporting stack needed to build end-to-end solutions: security, networking, observability, data, deployment, integration, and operations.

For others, the motivation may be different.

Maybe your goal is to deepen your expertise in security.
Maybe you want to better understand DevOps or platform engineering.
Maybe you’re an architect looking for a more complete view of the cloud.
Or maybe you lead teams and want a stronger framework for making technical decisions across domains.

The key is simple: identify your reason.

If your reason is only “I want the jacket,” your motivation will probably not survive the harder exams. But if your reason is “I want a deeper understanding of the cloud so I can make better decisions,” then the jacket becomes a meaningful milestone — not just a costume.

Finally, don’t underestimate the role of people and community in this journey.

Sharing the process with your colleagues and the broader community can make a huge difference. You not only motivate others to learn and grow, but you also create an environment where knowledge flows more naturally. In many cases, the people around you — your teammates, peers, and mentors — become your best teachers along the way.

In the end, the journey is not just about what you learn, but also about who you learn it with.

What people get wrong about the Golden Jacket

The biggest mistake is confusing certification with mastery.

Even studying hard and passing the exam is still not enough to make someone a great architect. Real depth still comes from practice, failure, reading documentation, building systems, debugging incidents, and seeing how theory behaves under constraints.

The certification process is incredibly useful, but it is not the end of learning. In fact, it should make you more humble.

That was one of the strongest feelings I had after completing the journey: not “I know everything,” but almost the opposite. I felt more responsibility to go deeper into the details, better understand technical trade-offs, read documentation more carefully, and keep sharpening my judgment.

That is a good sign.

Because the right outcome of a big milestone in tech is not arrogance. It is responsibility.

A few things that helped me

One of the best decisions I made was avoiding very long gaps between certifications.

When you leave too much time between exams, you forget things. The momentum disappears. The connections between domains get weaker. If you are going to do this seriously, I think it is better to maintain a rhythm that helps the knowledge compound.

Another important lesson: do not compare your path with someone else’s.

Do not compare your order of certifications.
Do not compare your pace.
Do not compare your number of failed attempts.
Do not compare your work context.

Some people have more hands-on exposure in security. Others live in data platforms. Others are already deep in networking. Some have employers that support study time and exam budgets. Some do not.

Your path should fit your goals and your reality.

Also, be ready to fail.

Not every exam goes the way you expect. Some questions feel ambiguous. Some domains expose your blind spots. Some exams simply hit you on a bad day. That is part of the process.

How to actually receive the physical Golden Jacket

This part is worth explaining because many people ask about it. The exact process may change over time, but the core principle appears consistent: you need to hold all active AWS certifications, and in some official event programs AWS has required those certifications to remain valid at the time of recognition or event pickup. Recent AWS event pages have shown Golden Jacket application forms for specific events, pickup through certification lounges, and event-based distribution rather than one single evergreen public request page. AWS also updates its certification catalog over time, including launches and retirements, which is why “all active certifications” matters more than memorizing a number forever.

So the most accurate advice I can give is:

1. Make sure you truly hold all active certifications.
2. Keep them active.
3. Ask your AWS contact, partner contact, or employer contact what current recognition path applies to your case.
4. Watch for event-specific Golden Jacket forms, especially around major AWS events.
5. Be patient, because logistics and distribution can vary by location.

In my case, being at an AWS Premier Partner helped because there was already a direct communication path with AWS, and the company was willing to cover the jacket. That kind of environment also creates something else that matters a lot: certification culture.

When several people in a company are pursuing certifications, talking about services, sharing notes, and learning together, the momentum becomes much stronger.

That culture matters more than most people think.

What to do after you get it

The Golden Jacket should not be the end of the story. If anything, it should be the beginning of a more useful phase.

Help other people learn.
Stay current on AWS service changes and new launches.
Experiment more.
Share your experiments publicly.
Plan your recertification strategy.
Build community impact.
Teach.
Mentor.
Speak.
Write.
Contribute.

AWS changes continuously. Certifications are updated. Exams retire. New ones launch. AWS itself has publicly changed the certification lineup over time, including retiring some specialty exams and introducing new role-based ones. So the Golden Jacket is not really a finish line. It is more like a public reminder that staying current is now part of your identity. For some people, that next step may be becoming an AWS Community Builder. For others, it may be becoming an AWS Ambassador (I explained here how to do this: I Became an AWS Ambassador: What It Took, What It Means, and Why It Matters), an SME, a teacher, or simply the person in their company who helps raise the technical bar. All of those are good paths.

Final thought

The AWS Golden Jacket is useful, but not because it gives you special access. It is useful because it pushes you through a journey that can fundamentally improve how you think.

It can make you broader.
It can make you more disciplined.
It can make you more credible.
It can make you more helpful to customers, teams, and communities.

But only if you treat it as a symbol of learning, not as a shortcut to status.

So yes, the jacket is shiny.
Yes, it gets attention.
Yes, it is fun to wear at AWS events.

But the real prize is not the fabric. It is the person you become while earning it.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com/, https://medium.com/@crhisto

Everyone talks about generating content with GenAI.

Almost no one talks about how to evaluate it.

And that’s where most systems break.

Generative AI has dramatically accelerated how quickly teams can create content. But in doing so, it has quietly introduced a harder problem:

How do you evaluate that content consistently, repeatedly, and at scale?

This is the part that often gets underestimated. Generating content is the easy demo. Governing its quality is the real engineering challenge.

Across enterprises, this challenge shows up in different ways. Marketing teams need content to follow tone and messaging guidelines. Compliance teams must ensure documents include required language. Platform teams want internal documentation reviewed for quality and consistency. Product teams care about SEO and accessibility. ML teams need dataset artifacts validated for completeness and policy alignment (See Table 1 for more examples).

The pattern is always the same: there is a standard — but it’s fragmented. It lives across documents, tribal knowledge, examples, policies, and reviewer habits. Manual review doesn’t scale. Static rules are too brittle. One-shot prompting is flexible, but often inconsistent and hard to reproduce.

What’s missing is not another prompt — it’s a system.

A system that can define how evaluation should work, refine that definition over time, and apply it consistently.

In this post, I explore a workflow that does exactly that: it generates a structured evaluation guideline (in a machine-readable format such as JSON — though it could also be represented in Markdown or similar formats), refines it iteratively using new inputs, applies it consistently to content, and validates the results using LLM-as-a-Judge techniques.

Along the way, it introduces key capabilities such as drift detection, external enrichment, benchmarking, and full traceability.

The result is a shift away from “ask the model to review this” toward something far more robust:

A system that can build its own evaluation standard, improve it over time, and check whether its own judgments remain trustworthy.

That’s where this approach becomes interesting — not just as a solution, but as a pattern for building more reliable, agentic GenAI systems.

Why this problem matters more in the GenAI era

Before LLMs, content evaluation was typically handled in one of three ways.

The first was deterministic validation: schemas, regexes, linting rules, checklists, and business logic. These approaches work extremely well when the problem is narrow and clearly defined. However, they start to break down when evaluation involves softer dimensions such as tone, ambiguity, clarity, structure, or domain-specific nuance.

The second approach was human review. Humans are flexible and context-aware, making them ideal evaluators. But they are also expensive, slow, and inherently inconsistent across reviewers, teams, and time.

The third, more recent shortcut is to rely on a single LLM prompt — essentially asking: “Review this content and tell me if it’s good.” This can work surprisingly well in prototypes, but it often leads to unstable and hard-to-reproduce results. The evaluation criteria are usually implicit, buried in prompt wording, and rarely versioned or traceable.

What teams actually need is not just an LLM reviewer, but a repeatable and structured evaluation system.

That’s why an architecture that addresses these limitations is so compelling. Instead of relying on ad hoc evaluations, it breaks the problem into clear stages: define the evaluation standard, refine it incrementally, apply it consistently, and validate the results. In practice, this approach is much closer to how mature, production-grade GenAI systems should be designed.

A concrete example

To make this more tangible, let’s walk through a simple scenario:

Imagine an e-commerce company that needs to review 10,000 product descriptions every day.

Each description is supposed to follow internal guidelines:

• include key product attributes,
• maintain a consistent tone,
• avoid restricted or misleading terms,
• and meet marketplace compliance requirements.

Today, this process is handled through a mix of manual review, scattered checklists, and a few brittle rules.

Some descriptions are too vague. Others are missing critical information. Some violate tone or compliance guidelines. The result is inconsistent quality — and a process that doesn’t scale.

Now imagine replacing that with a system that can:

• define what “good” looks like,
• apply that definition consistently across all content,
• and continuously improve its own evaluation criteria over time.

That’s exactly the kind of system we’ll build throughout this post.

The agentic idea hiding inside this architecture

At first glance, this might look like a content-quality pipeline. But there is a deeper GenAI pattern behind it.

This design is really an example of an agentic evaluation loop.

The system is not merely generating an answer. It is interacting with a sequence of artifacts and decisions:

• it creates a structured representation of the rules,
• it revises that representation when new evidence appears,
• it applies the rules to a target artifact,
• it critiques the result,
• and it can compare itself to ground truth.

That is much closer to an agent workflow than to a plain prompt-response interaction.

The source document lays out this pattern explicitly: the workflow begins with source files, extracts a guideline, refines that guideline iteratively, evaluates an input content piece, and can then use an LLM-as-a-Judge plus ground truth for validation. It also calls out optional enrichment by an external agent and traceability of the sources used across steps.

In GenAI terms, several important patterns show up here.

1. Structured output as a control surface

The first pattern is structured output. Instead of leaving the evaluation standard buried inside a prompt, the system materializes it as JSON.

That matters because JSON is not just an output format. It becomes a control surface for the whole system:

• it can be versioned,
• diffed,
• audited,
• reused across runs,
• enriched with metadata,
• and compared across iterations.

When GenAI systems become operationally important, structured artifacts like this are often the difference between “clever demo” and “maintainable system.”

2. Evaluator-optimizer loops

A second pattern is the evaluator-optimizer loop. One model pass creates or refines a guideline, and a later pass evaluates content against it. Sometimes a further pass judges the quality of that evaluation.

This is more reliable than a single monolithic prompt because the system separates responsibilities. One step focuses on defining standards. Another focuses on applying them. Another focuses on judging whether the application was sound.

That decomposition reduces prompt overload and gives you more places to measure quality.

3. LLM-as-a-Judge, but grounded

The document explicitly includes an LLM-as-a-Judge stage and recommends comparing outputs against expected or ground-truth references where available.

That is an important realism check. LLM-as-a-Judge is powerful, but it should not be treated as magic. It works best when grounded by one or more of these:

• a clearly defined rubric,
• reference outputs,
• comparison baselines,
• benchmark datasets,
• human spot checks.

Used well, it becomes a scaling tool for evaluation. Used casually, it becomes another layer of unverified opinion.

4. Tool-using agents instead of pure prompting

The workflow also maps naturally to a tool-using agent pattern. An agent can retrieve source files, read prior guideline versions, call the model for refinement, persist artifacts, compute diffs, compare scores, and trigger a judge step.

This is where modern agent frameworks become useful. AWS describes Strands Agents as a model-driven SDK where developers define prompts and tools, and the model plans and executes the next steps using those tools. AWS also describes Amazon Bedrock AgentCore as a platform for building, deploying, and operating agents securely at scale, with services such as runtime, memory, gateway, browser, and code interpreter.

That combination fits this content-evaluation pattern well: Strands can express the agent logic and tool use, while AgentCore can help operationalize it.

A better mental model: don’t ask the model to evaluate content

A useful reframing is this: Do not ask the model to directly decide whether content is good. Ask the model to first define how goodness should be measured, then make it follow that structure.

Key Insight

Don’t ask the model to evaluate content. Ask it to define how evaluation should work — and then follow that structure.

That is a much stronger pattern. The moment the standard becomes explicit, you gain several advantages:

• consistency improves,
• outputs become easier to compare,
• errors become easier to debug,
• version drift becomes visible,
• and benchmarking becomes possible.

This is also one of the most important “GenAI reality” lessons. Reliability usually does not come from a better prompt alone. It comes from introducing more structure around the model.

A practical agentic architecture

A realistic implementation on AWS could look like this:

1. Data Storage (Amazon S3)
Amazon S3 stores all core artifacts, including source files, guideline versions, evaluation outputs, and benchmarking results. This ensures durability, traceability, and easy version management.

2. Model Layer (Amazon Bedrock)
Amazon Bedrock provides the foundation models used across the workflow — for guideline generation, content evaluation, and LLM-as-a-Judge validation.

3. Orchestration Layer (Strands Agent)
A Strands-based agent orchestrates the end-to-end process. It leverages tools to:

• Read and process source files
• Generate and persist structured JSON guidelines
• Compare revisions across iterations
• Compute evaluation metrics and scores

4. Agent Runtime & Production Layer (Amazon Bedrock AgentCore)
Amazon Bedrock AgentCore provides the production-grade environment to run the agent reliably at scale, including:

• Session management and memory
• Secure tool access
• Scalable execution
• Advanced capabilities such as code execution or browser-based enrichment

5. Compute & Deployment Options (AWS Lambda / Amazon ECS)
Supporting components can be deployed using AWS Lambda for event-driven workloads or Amazon ECS (with Fargate) for containerized, long-running processes, depending on system requirements.

The most important thing here is not a specific service choice. It is the separation of concerns:

• artifact generation,
• artifact refinement,
• artifact application,
• artifact validation.

That separation is what makes the workflow stable enough to evolve.

Example 1: a simple Strands agent for guideline extraction

In our running example, the system begins by analyzing existing product guidelines, past high-quality descriptions, and relevant compliance rules. From these inputs, it generates a structured guideline — represented as JSON — that defines what a “good” product description looks like, including required attributes, tone, and constraints.

The goal of this first step is not to evaluate content yet, but to explicitly define the evaluation standard.

The following example shows the general pattern. Strands allows you to define agents with tools, and its Python SDK makes it easy to create custom tools using the @tool decorator. This enables the agent to interact with external data (e.g., reading source documents or persisting outputs) as part of its reasoning process.

from strands import Agent, tool
import json

@tool
def load_source_text(path: str) -> str:
    """Load a source guideline document from local storage or S3-mounted path."""
    with open(path, "r", encoding="utf-8") as f:
        return f.read()

@tool
def save_guideline(path: str, guideline_json: str) -> str:
    """Persist a guideline JSON artifact."""
    with open(path, "w", encoding="utf-8") as f:
        f.write(guideline_json)
    return f"Saved guideline to {path}"

SYSTEM_PROMPT = """
You are a content-evaluation architect.

Your job is to extract a domain-specific evaluation guideline and return it as strict JSON.
The JSON must include:
- domain
- version
- categories
- checks
- scoring_approach
- rationale_summary
- source_references

Do not return prose outside the JSON.
"""

agent = Agent(
    system_prompt=SYSTEM_PROMPT,
    tools=[load_source_text, save_guideline]
)

result = agent("""
Read the source file at ./inputs/seo_guidelines.md.
Create a normalized evaluation guideline for HTML pages.
Then save it to ./artifacts/guideline_v1.json.
""")

print(result)

This example is intentionally simple, but it highlights a critical design choice:

The model is not asked for a vague review. It is asked to produce a durable, structured evaluation artifact.

That shift — from implicit judgment to explicit standards — is what enables consistency, traceability, and continuous improvement in later stages of the system.

Example 2: iterative refinement as a first-class pattern

One of the most important ideas in this approach is that guideline generation should be iterative, not fully regenerated on every run. This significantly reduces cost, preserves prior knowledge, and allows the evaluation standard to evolve in a controlled and transparent way.

In our running example, new information is constantly introduced — such as updated compliance rules or newly curated high-quality product descriptions. Instead of rebuilding the guideline from scratch, the system incrementally refines it, improving its understanding of what “good” looks like over time.

This turns the guideline into a living artifact, rather than a disposable output.

Strands supports this pattern through hooks and re-invocation mechanisms, which make it straightforward to implement refinement loops. These capabilities align naturally with the evaluator–optimizer pattern, where each iteration builds on the previous one.

from strands import Agent
from strands.hooks import AfterInvocationEvent

MAX_REFINEMENT_ROUNDS = 3
iteration = 0

agent = Agent(system_prompt="""
You maintain a content evaluation guideline in JSON.
At each step, refine the current guideline using the newly provided source text.
Preserve previous valid categories unless the new source clearly contradicts them.
Always return valid JSON only.
""")

async def refinement_hook(event: AfterInvocationEvent):
    global iteration
    if iteration < MAX_REFINEMENT_ROUNDS and event.result:
        iteration += 1
        event.resume = (
            f"Review your previous JSON and improve it using the next source file. "
            f"This is refinement iteration {iteration} of {MAX_REFINEMENT_ROUNDS}. "
            f"Keep the output strict JSON."
        )

agent.add_hook(refinement_hook)

result = agent("""
Start from guideline_v1.json and refine it with the policies in ./inputs/accessibility_rules.md.
""")

Conceptually, this is the shift from a static reviewer to an adaptive system.
The guideline is no longer a one-time artifact — it evolves with new data, new constraints, and better examples, becoming progressively more accurate and useful over time.

Example 3: using AgentCore Code Interpreter to verify scoring logic

Once the system begins producing structured evaluation reports, an important question emerges:

How do we verify that the scoring logic is actually correct?

This is where deterministic validation becomes valuable.

In our running example, the system may evaluate thousands of product descriptions and generate JSON reports with section-level scores, aggregate scores, and drift indicators across versions. While an LLM can reason about the results, some parts of the workflow — such as score calculations, deltas, and metric comparisons — are better handled with code.

This is an important production pattern: use the model for judgment and interpretation, but rely on tools for deterministic verification.

With AgentCore Code Interpreter, the agent can execute Python code in a managed environment to validate calculations, compare outputs across versions, and identify significant changes in the results. This helps ensure that the evaluation pipeline is not only intelligent, but also auditable and mathematically consistent.

from strands import Agent
from strands_tools.code_interpreter import AgentCoreCodeInterpreter

code_interpreter_tool = AgentCoreCodeInterpreter(region="us-west-2")

SYSTEM_PROMPT = """
You are an evaluation auditor.
When given evaluation reports in JSON, use Python code to:
1. verify score calculations,
2. compare results across versions,
3. compute drift deltas,
4. summarize statistically significant changes.

Return a concise explanation plus the validated metrics.
"""

agent = Agent(
    tools=[code_interpreter_tool.code_interpreter],
    system_prompt=SYSTEM_PROMPT
)

response = agent("""
Load two JSON reports:
- ./artifacts/eval_report_v3.json
- ./artifacts/eval_report_v4.json

Verify whether the overall score is correctly derived from section scores.
Then compute the delta by category and identify the three largest changes.
""")

print(response.message["content"][0]["text"])

This example highlights an important principle for agentic systems in production:

Let the model reason about what should be inspected, but let tools verify what can be computed exactly.

That combination makes the system more robust, transparent, and trustworthy — especially when evaluation outputs begin to influence business decisions or downstream automation.

Example 4: operationalizing the agent with Amazon Bedrock AgentCore

So far, we’ve focused on building the workflow. But in practice, the hardest part is not creating the system locally — it’s running it reliably in production.

Evaluation is rarely a one-off task. In real-world scenarios, the system must handle repeated workloads, maintain context across sessions, ensure traceability, and operate securely at scale.

This is where Amazon Bedrock AgentCore becomes relevant.

AgentCore provides a framework-agnostic environment for deploying and operating agents in production. It offers capabilities such as:

• managed runtime and scaling
• session handling and memory
• controlled tool access
• secure execution environments
• support for advanced capabilities like code execution or browser-based enrichment

Together, these features allow you to move from a prototype to a production-grade agentic system.

A simplified invocation example using the invoke_agent_runtime API looks like this:

import boto3
import json

client = boto3.client("bedrock-agentcore")

payload = json.dumps({
    "prompt": """
    Evaluate ./inputs/page.html against guideline_v4.json.
    Return JSON with section scores, mismatches, suggestions, and rationale_summary.
    """
}).encode()

response = client.invoke_agent_runtime(
    agentRuntimeArn="arn:aws:bedrock-agentcore:us-west-2:[id :) ]:runtime/my-evaluator",
    runtimeSessionId="content-eval-session-001",
    payload=payload
)

print(response)

In our running example, this could represent a production system evaluating thousands of product descriptions per day — each request executed as part of a managed session, with full traceability and controlled access to tools and data.

This matters because evaluation is not just a technical step — it’s an operational capability.
You need to support:

• repeatable and scalable execution
• consistent environments across runs
• auditability of results
• safe rollout of changes to guidelines and evaluation logic

Moving from local workflows to AgentCore is what transforms this pattern from a clever prototype into a reliable, enterprise-ready system.

Why this pattern is especially relevant now

The use cases listed in Table 1 are broad for a reason. Whether it’s code review, policy compliance, SEO and accessibility audits, academic writing, brand guideline enforcement, e-commerce validation, incident reports, or dataset quality checks — they all share the same underlying structure.

Across these domains, the problem consistently involves:

• a changing standard,
• imperfect and evolving source material,
• a mix of objective and subjective criteria,
• and the need for scalable, repeatable evaluation.

These are inherently difficult problems to solve with traditional approaches.

This is precisely where GenAI can provide real value — but only when it is wrapped in structure. Without that structure, you get inconsistent and hard-to-trust outputs. With it, you unlock systems that are not only flexible, but also reliable, auditable, and capable of improving over time.

The production lesson: trust comes from process, not from eloquence

A final point is worth making explicitly.

In early GenAI prototypes, teams often get impressed by eloquent model output. In production, eloquence matters much less than process.

A trustworthy evaluator is not one that sounds smart. It is one that:

• uses explicit rubrics,
• stores evaluation artifacts,
• can be benchmarked,
• shows its evidence,
• supports drift analysis,
• and can be cross-checked by a second mechanism.

That is why the original proposal’s emphasis on ground truth, benchmarking, traceability, and version drift is so strong. Those are not “nice to have” details. They are what makes the architecture credible.

In this scenario, what started as a manual review process becomes a scalable, self-improving system — capable of evaluating thousands of product descriptions daily while continuously refining its own standards.

Conclusion

The real opportunity here is bigger than content QA.

This pattern points toward a broader class of GenAI systems where the model does not just generate outputs. It helps define standards, improve them, apply them consistently, and measure how reliable the process remains over time.

That is a far more useful direction for enterprise GenAI.

By combining structured JSON guidelines, iterative refinement, tool-using agents, LLM-as-a-Judge validation, and production infrastructure such as Amazon Bedrock AgentCore, teams can move from one-off review prompts to evaluation systems that are adaptive, auditable, and operationally realistic.

And in my opinion, that is where a lot of the real value of agentic AI will be found over the next few years: not only in generating more content, but in building systems that can govern quality at the speed of generation.

Beyond Static Rules: Building Agentic Content Evaluation Systems on Amazon Bedrock was originally published in Loka Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why another Claw guide?

OpenClaw is one of the most powerful AI agent frameworks right now. It can read your emails, run code, connect to your apps… and if you’re not careful, it can also break things. The problem? There isn’t just one OpenClaw anymore. There are dozens of variants — NanoClaw, NemoClaw, PicoClaw, ZeroClaw — each optimized for something different: security, speed, cost, or scale.

So… which one should you actually use?

Some weeks ago I published a piece called “We Built Agents That Think. OpenClaw Builds Agents That Act” in which I argued that OpenClaw signals a shift away from reasoning‑centric multi‑agent systems such as AWS AgentCore and LangGraph toward action‑oriented agent architectures. (You can find that post here: We Built Agents That Think — OpenClaw Builds Agents That Act). After that article went live I spent hours discussing different approaches and system tweaks with colleagues and friends and fielded a steady stream of questions: which “Claw” is best? In the meantime I began tinkering with various forks and variants of OpenClaw to see how they differ in practice.

Those experiments and conversations made one thing clear: the community needs a more comprehensive comparison. The Claw ecosystem is evolving at breakneck speed. New variants appear almost weekly — each promising better security, lower resource usage, or broader integrations. It’s exciting… but also confusing.

To help make sense of it all, I’ve put together this guide. It distills what I’ve learned about the main variants — OpenClaw, NanoClaw, NemoClaw, PicoClaw, ZeroClaw, NullClaw, NanoBot, Ironclaw, and TinyClaw — and, more importantly, how to think about choosing between them and deploying them in practice.

Before we go deeper, here’s my take:

Most people should NOT start with OpenClaw.
They should start with NanoClaw.

Not because OpenClaw is bad — but because it’s too powerful without strong isolation, and most users underestimate the risks that come with that level of autonomy.

Let’s break down why.

Note: This reflects the ecosystem as of the publication date. Things are moving fast, so expect new variants and updates to appear quickly.

The rise of autonomous AI agents

In early 2026 an open‑source project called OpenClaw took the internet by storm. Austrian developer Peter Steinberger released a prototype called Clawdbot that allowed large‑language‑model (LLM) agents to run locally on a user’s machine and connect to messaging apps like WhatsApp, Telegram and Slack. After a handful of renamings and rapid viral growth, the project was re‑named OpenClaw and quickly became the fastest‑growing open‑source project in history. Users could instruct a “claw” through chat and the agent would read emails, browse the web, run shell commands and chain multi‑step workflows. Within three weeks the project’s GitHub repository had accumulated hundreds of thousands of stars and thousands of forks, turning OpenClaw into the de‑facto “operating system for personal AI”.

However, giving an LLM persistent memory and the ability to execute arbitrary commands on your machine introduces enormous security risks. Security researchers quickly found multiple remote‑code‑execution vulnerabilities and prompt‑injection paths, and users discovered that a misbehaving agent could delete files, leak credentials or send private conversations into public channels. Recognizing the risk, the open‑source community created a series of variants — NanoClaw, NemoClaw, PicoClaw, ZeroClaw, NullClaw, NanoBot, Ironclaw and TinyClaw — each re‑imagining the agent architecture to emphasize security, resource efficiency or enterprise scalability. This guide synthesizes open documentation, credible blog posts and official announcements to compare these projects and provide practical recommendations for developers, hobbyists and enterprises.

Quick Answer

If you just want the answer:

• Use OpenClaw → if you want full power (and accept risk)
• Use NanoClaw → if you want safety + flexibility
• Use ZeroClaw → if you want performance + determinism
• Use NemoClaw → if you are enterprise

Now let’s break down why.

OpenClaw — the monolithic powerhouse

OpenClaw is designed to be a full‑featured personal assistant with a broad integration ecosystem. According to a DEV Community analysis, OpenClaw’s codebase approaches 500 000 lines, includes over 70 software dependencies and contains 53 configuration files. It supports 50+ native integrations spanning SaaS platforms, cloud databases and messaging services, and can route calls to multiple LLM back‑ends — including models from OpenAI, Anthropic, and even local models running on consumer hardware. Persistent state management allows the agent to recall context across days or weeks of continuous operation.

OpenClaw’s immense flexibility comes at a cost. Its security model relies primarily on application‑layer controls such as API whitelists and device‑pairing codes. Because the agent executes code directly on the host operating system, running it safely often requires complex infrastructure: hardened virtual machines, read‑only file systems, strict VLAN isolation and custom AppArmor profiles. The large codebase also creates a huge attack surface. Security researchers note that having hundreds of contributors pushing code at breakneck speed into a half‑million‑line project makes auditing practically impossible. As a result, most professional users deploy OpenClaw inside isolated environments or on a dedicated “agent box” to prevent damage (like me!).

Nevertheless, OpenClaw remains the most feature‑rich framework. It provides out‑of‑the‑box support for voice commands, a live canvas, native mobile apps (macOS, iOS and Android) and a host of channels (Telegram, WhatsApp, Discord, Signal, iMessage and Teams). With more than 330 000 GitHub stars (as of March 2026) and an active Discord community, it has the largest ecosystem of plugins and third‑party skills. OpenClaw is best suited for developers who need maximum flexibility, have the ability to harden infrastructure themselves and are comfortable accepting some security risk. For individuals without an isolated machine, caution is advised.

When to use OpenClaw

• Enterprise or research teams that require a broad integration ecosystem and can provision isolated hardware.
• Power users who want to experiment with advanced multi‑model routing or build custom skills.
• Developers willing to maintain complex infrastructure and apply strict OS‑level sandboxing to mitigate security risks.

NanoClaw — security‑first minimalism

NanoClaw was created by developer Gavriel Cohen as a response to OpenClaw’s security issues. In a TechFirst interview, Cohen explained that OpenClaw’s half‑million‑line codebase and dozens of dependencies make it fundamentally insecure and difficult to audit. He set out to build a safer alternative that could replicate the benefits of OpenClaw without exposing the host machine. The result is NanoClaw, a lightweight framework whose core logic is roughly 500 lines of code; even after adding containerization, the repository remains around 3 000 lines. NanoClaw tracks the token count of its own repository (≈ 36 000 tokens), meaning the entire project fits within the context window of large models like Claude Opus, enabling automated audits and modifications.

The defining feature of NanoClaw is OS‑level isolation. Each agent session runs inside an independent Linux container (Docker on Linux or Apple Container on macOS). This ensures that if a model hallucinates or a prompt‑injection attack occurs, the damage is limited to the container and cannot harm the host operating system. The sandboxed environment allows the agent to install packages, run shell commands and call external APIs without compromising the computer. NanoClaw includes only a handful of dependencies, reducing the risk of supply‑chain attacks.

Despite its small size, NanoClaw is highly extensible. Its default configuration supports WhatsApp, Slack, Discord, Signal and other messaging channels. Users can ask the agent to “add voice messages” or “add image generation,” and because the entire codebase fits in the model’s context window, the agent can modify its own codebase in a single call. The community has grown quickly; the GitHub repository has over 25 000 stars github.com and an active Discord with more than 600 developers.

Security and risk profile

NanoClaw’s container isolation mitigates many of the problems that plague OpenClaw. Because each agent runs in its own container, cross‑channel credential leakage is reduced; the worst that an agent can do is corrupt its own container. However, persistent containers introduce the risk of prompt‑injection persistence. Malicious instructions hidden in files today can affect the agent weeks later if its memory is not reset. NanoClaw’s continuous lifespan also increases the chance of behavioral drift. For tasks requiring deterministic outputs or auditable pipelines, lighter variants like ZeroClaw or ZeptoClaw may be preferable.

When to use NanoClaw

• Security‑conscious individuals who want a personal assistant but lack the resources to build complex isolation.
• Developers looking to experiment with containerized agents, custom skills and multi‑agent swarms.
• Small teams needing cross‑platform messaging integrations without large hardware requirements.

NemoClaw — enterprise‑grade safety and scale

In March 2026 NVIDIA announced NemoClaw, an open‑source AI‑agent platform built for enterprises. The NemoClaw stack installs via a single command using the NVIDIA Agent Toolkit and includes the OpenShell runtime, which sandboxes OpenClaw agents to enforce policy‑based security and privacy guardrails. NVIDIA positions NemoClaw as “the operating system for personal AI” but with enterprise‑class security. Unlike consumer variants, NemoClaw is designed for regulated industries, large‑scale deployments and sensitive data processing.

NemoClaw integrates deeply with NVIDIA NeMo, Nemotron models and NIM (NVIDIA Inference Microservices) to provide GPU‑accelerated inference and training. It supports both local models (running on GeForce RTX PCs, RTX Pro workstations or DGX servers) and cloud models, routing requests through a privacy router. Hardware agnosticism means the framework can also run on AMD and Intel processors, reflecting NVIDIA’s ambition to own the agent runtime across the entire industry.

The platform emphasizes multi‑layer security: OpenShell enforces sandboxing and policy controls, while NemoClaw’s enterprise toolkit allows organizations to define permission scopes, data‑access policies and network boundaries. Partnerships with Salesforce, Cisco, Google, Adobe and CrowdStrike illustrate NVIDIA’s plan to integrate NemoClaw agents into customer‑relationship management, network management, cloud services and cybersecurity. The release roadmap shows that NemoClaw will be unveiled at GTC 2026, followed by an enterprise adoption phase.

When to use NemoClaw

• Large enterprises that need an open-source agent platform with strict security controls and policy governance.
• Organizations requiring integration with NVIDIA’s NeMo framework, Nemotron models or GPU‑accelerated inference.
• Developers building products that must comply with data‑privacy regulations or operate within regulated industries.

Other notable Claw variants

PicoClaw — ultra‑lightweight assistant for embedded devices

PicoClaw is written in Go and designed to run on $10 RISC‑V/ARM boards. According to the Claw AI Agent Family blog, it uses under 10 MB of RAM and boots in under one second. Around 95 % of its code was generated by an AI agent during a self‑bootstrapping process. PicoClaw supports basic messaging channels and voice integration and is ideal for IoT or home‑automation projects where hardware is limited.

ZeroClaw — performance‑focused Rust implementation

ZeroClaw is a re‑implementation of OpenClaw in Rust. Its architecture treats every subsystem, provider and memory as a swappable trait. The binary is approximately 3.4 MB and uses under 5 MB of RAM. ZeroClaw features a sophisticated memory system combining vector and full‑text search with optional PostgreSQL, and a built‑in migration tool for OpenClaw. Cold‑start times are under 10 milliseconds on ARM64 edge nodes, making it suitable for edge‑compute or mobile environments. However, its community and ecosystem are smaller than OpenClaw’s, and features like plugin marketplaces are still maturing.

NullClaw — performance extreme in Zig

NullClaw pushes minimalism further by compiling to a 678 KB static binary that uses about 1 MB of RAM and starts in under 2 milliseconds. Despite its size, it has 22+ providers, hardware‑peripheral support for Arduino and Raspberry Pi, and around 2 000 tests. NullClaw prioritizes performance and extreme resource efficiency, making it ideal for microcontrollers, low‑power servers or embedded systems. Its small footprint and compiled nature also simplify auditing and reduce the risk of supply‑chain vulnerabilities.

Ironclaw — WebAssembly sandbox for maximum security

Ironclaw emphasizes security above all else. Every tool runs inside a WebAssembly sandbox and credentials are never exposed directly to the tools. A multi‑layer prompt‑injection defense reduces the risk of malicious input. Because of its strict isolation, Ironclaw currently offers limited channel support but is ideal for highly sensitive data or workloads requiring strong isolation.

NanoBot — readable research agent

NanoBot is a Python implementation with roughly 4 000 lines of code, about 99 % smaller than OpenClaw. Its goals are readability and research friendliness rather than performance. It provides a simple entry point for developers who want to understand the agent loop or extend it for academic experiments.

TinyClaw — multi‑agent orchestration

TinyClaw is unique among the Claw family because it orchestrates multiple agents working together. It enables roles such as coder, writer and reviewer to collaborate with a live dashboard. This design is suited for projects where tasks can be decomposed across specialized agents, and users need to supervise or adjust workflows in real time.

ZeptoClaw — stateless, deterministic actions

Though not as widely known, ZeptoClaw is a stateless, single‑action agent variant. It performs a single deterministic transformation and then terminates, ensuring perfect repeatability. ZeptoClaw uses 5–10 MB of RAM and is ideal for high‑volume batch transformations where reliability is paramount.

Comparative Tables

Selecting the right variant for your use case

When choosing among the Claw variants, consider hardware constraints, security posture, required integrations, and tolerance for agent autonomy and drift.

Personal developers and hobbyists

If you’re exploring AI agents on your own machine for coding assistance, file management or chat workflows:

• Choose NanoClaw if you prioritize safety but want a persistent assistant that can handle multi‑step tasks and you don’t mind its container overhead. Run it on a desktop or laptop with at least 100 MB of free RAM. For very low‑power hardware (Raspberry Pi or ESP32), PicoClaw or NullClaw are better suited because they use < 10 MB of RAM.
• Avoid OpenClaw unless you can dedicate a separate machine. The monolithic codebase and heavy resource use (> 1 GB RAM) make it risky on everyday laptops.
• Use NanoBot if your goal is to learn how an agent loop works or to build a new framework. Its small Python codebase is readable and easy to modify.

Small teams and startups

Teams building prototypes, managing group chats, or automating common workflows can pick:

• NanoClaw for flexible, containerized agents that can be extended quickly using AI‑assisted code generation. Ensure you reset containers periodically to avoid prompt‑injection persistence.
• ZeroClaw for deterministic pipelines, continuous integration or low‑latency edge tasks. Its 3.4 MB Rust binary offers excellent performance and memory efficiency.
• TinyClaw if your workflow involves multiple specialized agents collaborating on tasks (e.g., coder + reviewer + deployer). Use a dashboard to supervise tasks.

Enterprises and regulated industries

Organizations subject to strict compliance requirements (financial services, healthcare, defence) should avoid general‑purpose clones and choose:

• NemoClaw (upon release) for enterprise‑grade security, compliance and privacy. It integrates with NVIDIA’s NeMo, Nemotron and NIM frameworks and supports hardware‑agnostic deployments while providing policy‑based guardrails.
• Ironclaw if your risk tolerance is near zero and you need WebAssembly sandboxing. It’s especially suited for workflows requiring deterministic and auditable execution.
• ZeroClaw or ZeptoClaw for deterministic, repeatable tasks (data validation, ETL pipelines, simulation) where reliability trumps autonomy.

Cloud deployment options for OpenClaw and its variants

Running a persistent AI assistant on your laptop can expose sensitive files and burn through hardware resources. Most guides therefore recommend moving the Gateway component of OpenClaw (and its variants) to a remote server. A cloud VM can stay online 24/7, isolate the agent from your local drive and provide predictable performance. As a DEV Community guide notes, deploying OpenClaw on a cloud VM like Google Cloud Platform is ideal because it keeps the assistant available and isolates sensitive data. The following subsections summarise major cloud providers and hosted platforms that offer straightforward paths to run OpenClaw or compatible variants.

Choosing the right deployment environment

The table above illustrates that there is no one‑size‑fits‑all cloud provider. Your decision should balance budget, ease of deployment, geographic region, scalability and security requirements:

• Budget‑constrained hobbyists should consider Hetzner, Contabo or DigitalOcean. Hetzner’s CX series provides a dependable baseline for ~$4–6/month, while Contabo offers far more RAM per dollar and is ideal for local model inference. DigitalOcean’s 1‑click image is slightly pricier but delivers strong defaults and per‑second billing.
• Non‑technical users who want an agent quickly without managing servers can choose a managed platform like Hostinger’s 1‑click product, xCloud or Northflank. These services handle installation, updates and security but cost more per month.
• Developers requiring scalability or integration with existing cloud infrastructure may favour AWS (Lightsail or EC2) or Azure. AWS integrates well with Bedrock and other services, while Azure offers Bastion‑based isolation and enterprise networking. Note, however, that Azure’s costs can be high once you factor in Bastion.
• Security‑sensitive or enterprise deployments might choose Azure, OVHcloud or NemoClaw on NVIDIA DGX/enterprise hardware. Azure’s NSG and Bastion model allow strict access control; OVHcloud includes DDoS protection and daily backups; NemoClaw offers policy‑based guardrails and GPU acceleration.
• Zero‑cost experiments can leverage Oracle Cloud’s free tier (ARM) but must deal with limited capacity and ARM‑specific issues.

Advice for variant deployment

Not all Claw variants have the same resource requirements:

• OpenClaw requires at least 4 GB RAM and benefits from SSD or NVMe storage; cloud providers with 2 vCPUs and 4 GB RAM (DigitalOcean $24/month or Hetzner CX33) handle basic workloads. For browser automation or local model inference, choose providers offering 8 GB RAM or more (Contabo, OVHcloud or Kamatera).
• NanoClaw and NanoBot consume less memory and can run on 1–2 GB RAM; these variants suit smaller instances like DigitalOcean’s $6/month droplet or Hetzner’s CX11. However, ensure your plan provides persistent storage and container support.
• PicoClaw, ZeroClaw, NullClaw and ZeptoClaw have tiny footprints and can run on ARM boards or free tiers like Oracle Cloud’s A1 Compute. They are ideal for IoT or embedded deployments.
• NemoClaw and heavy multi‑agent setups demand GPU acceleration and enterprise networking. NVIDIA’s DGX servers or AWS/Azure instances with GPUs are appropriate.

In summary, moving your agent to the cloud offers better uptime, isolation and scalability than running it on your laptop. With choices ranging from free ARM machines to enterprise‑grade managed platforms, you can match the deployment environment to your technical comfort, security posture and budget. These cloud options complement the variant comparison above, ensuring you can deploy the right “claw” in the right place.

Recommended publishing venues for your blog

Given the technical nature of this analysis and the interest among AI developers, the following platforms are appropriate for publishing a 12–15‑minute read:

• Medium’s AI/DevOps channels — Many articles in this ecosystem (e.g., The State of the Claw World and comparisons of OpenClaw vs NanoClaw vs NemoClaw) appear on Medium. Medium reaches a broad audience of developers, tech executives and enthusiasts and supports long‑form writing.
• DEV Community — The Architecting the Agentic Future article provides a balanced technical comparison and reaches a developer‑centric audience. DEV emphasizes open‑source and developer tooling, making it ideal for in‑depth technical guides.
• Personal blogs or Substack — For more control and the ability to embed code snippets, interactive demos and update posts, a self‑hosted blog (like the Claw AI Agent Family post) or a Substack newsletter gives you full editorial freedom. Cross‑posting to LinkedIn can also attract enterprise readers.

Conclusion

The “claw” ecosystem exploded from a single open‑source side project into a sprawling family of agent frameworks within months. OpenClaw pioneered the idea of local, autonomous AI assistants but quickly ran into security concerns due to its monolithic architecture and lack of isolation. NanoClaw’s minimalist, container‑centric design dramatically improves safety while maintaining flexibility, though its persistent memory can introduce drift. NVIDIA’s NemoClaw aims to take these ideas to the enterprise with built‑in policy enforcement, privacy routers and GPU‑accelerated inference. Beyond these flagship projects, variants like PicoClaw, ZeroClaw, NullClaw, Ironclaw, NanoBot, TinyClaw and ZeptoClaw offer specialised solutions tailored to constrained hardware, deterministic pipelines or multi‑agent collaboration. Choosing the right “claw” depends not only on features but also on hardware constraints, risk tolerance, desired autonomy and community support.

With AI agents poised to become a foundational layer of personal and enterprise computing, understanding the trade‑offs of these frameworks is critical. By aligning your choice with your use case — whether you’re a hobbyist exploring automation, a startup building a new product or an enterprise deploying mission‑critical workflows — you can harness the power of autonomous agents while minimising risk and maximizing efficiency.

If you’re experimenting with any of these Claws, I’d love to hear what you’re using and why. The ecosystem is evolving fast — and the “best Claw” today might not be the best one in a few weeks.

For more posts, check out my Substack and my Medium:
https://crhisto.substack.com/, https://medium.com/@crhisto