TL;DR: I built the same browser agent twice — once with 500 lines of Python, once with 7 lines of JSON. The second one took 5 minutes. The agent harness layer is becoming the real competitive advantage, not the model.

Last month, I built a browser automation agent. Playwright. Custom orchestration. Login handlers. Error retries. Session management. React-aware form filling. Anti-detection scripts. 500+ lines of Python.

This week, I built the same thing:

{
  "model": { "provider": "bedrock", "modelId": "us.anthropic.claude-sonnet-4-6" },
  "tools": [{ "type": "agentcore_browser", "name": "browser" }],
  "systemPrompt": "You are a web browsing assistant."
}

Deploy. Invoke. It browses websites, extracts data, fills forms. Seven lines. Zero orchestration code.

But here's the thing most people miss: I kept both versions. And that's the real insight.

What Changed (and What Didn't)

The 500-line script is better for its specific job. It runs faster, cheaper, and more reliably. Because it doesn't need AI — the steps are known.

The 7-line harness is better for everything else. Research tasks. Data extraction from unfamiliar sites. Competitive analysis. Anything where the steps aren't known in advance.

This is my POV: deterministic + AI is the right architecture. Don't use a $0.03/call model to click a button you can click with Playwright for free. But don't write 500 lines of Playwright when 7 lines of config can handle it.

The Harness Is the New Battleground

Everyone's talking about which model is best. Claude vs GPT vs Gemini. Benchmarks. Context windows. Reasoning scores.

That conversation is becoming irrelevant.

Models are commoditizing. Claude Sonnet 4.6 and GPT-5.5 are both "good enough" for most agent tasks. The real question is: what wraps around the model to make it actually work in production?

That's the harness — the orchestration loop, tool execution, memory, security, compute isolation. And every cloud provider is racing to own it:

This is the container orchestration war all over again. In 2015, everyone had containers. The question was who manages running them. Kubernetes won, and whoever controlled K8s controlled where workloads ran.

In 2026, everyone has models. The question is who manages running agents. Whoever controls the harness controls the next decade of cloud spend.

How AgentCore Harness Works

You (prompt) → AgentCore Harness → Bedrock Model (reasoning)
                    ↓                      ↓
              Firecracker microVM    Tool selection
              (isolated per session)       ↓
                    ↓              AgentCore Browser / Shell / Code
              Persistent memory    
              (across sessions)    
                    ↓
              Streamed response → You

What AWS handles: compute, orchestration loop, tool invocation, memory, auth, observability.
What you handle: a JSON config and a prompt.

Each session runs in its own Firecracker microVM — the same isolation technology behind Lambda. Not a container. A VM. One session can't see another's data, cookies, or credentials.

Getting Started (I Actually Ran This)

# Install CLI
sudo npm install -g @aws/agentcore@preview

# Create project
agentcore create --name browseragent --model-provider bedrock
cd browseragent

# Add browser tool
agentcore add tool --harness browseragent --type agentcore_browser --name browser

# Set target account + region
# Edit agentcore/aws-targets.json: [{"name":"default","region":"us-west-2","account":"YOUR_ACCOUNT"}]

# Deploy (~3 min)
agentcore deploy --yes

# Use it
agentcore invoke --harness browseragent --stream \
  --prompt "Go to example.com and describe what you see"

Output from my actual run:

🔧 Tool: browser
⚡ 6005 in · 110 out · 2.2s
Here's what's on the page at example.com:
### Example Domain
The page contains: "Example Domain" heading, body text about documentation use,
and a "Learn more" link to IANA documentation.

Real. Not a demo. Not a screenshot from someone else's blog.

Production Considerations

⚠️ Gotcha I hit: The harness execution role needs bedrock:Converse and bedrock:ConverseStream permissions, plus aws-marketplace:ViewSubscriptions for 3P models. The default CDK policy only includes bedrock:InvokeModel. I had to add permissions manually.

When NOT to Use Harness

• Deterministic automation (same steps every time) → Playwright. Cheaper, faster, more reliable.
• Complex multi-agent workflows → Strands Agents SDK with AgentCore Runtime. More control.
• Existing framework investment (LangChain/CrewAI) → Use AgentCore tools standalone.
• Production workloads → Wait for GA. It's preview.

Bottom Line

The model is the brain. The harness is the body. Most teams are spending all their time picking the brain and hand-building the body from scratch every time.

AgentCore Harness lets you stop building bodies and start building solutions. For 80% of agent use cases, config beats code. For the other 20%, write code — but use the harness infrastructure underneath.

The teams still hand-coding agent orchestration loops are building technical debt. The same way teams hand-coding REST APIs built technical debt before API Gateway existed.

The question isn't whether to adopt managed agent infrastructure. It's whether you'll be building on it — or competing against someone who already is.

Ajit NK — AWS Community Builder, APN FasTrack Partner. Building AI agent solutions at CloudNestle.
"The model is the brain. The harness is the body. I build the body."

📚 Sources:

• AgentCore Harness docs
• What's New announcement (Apr 22, 2026)
• Strands Agents SDK