Forem: Nathaniel Hamlett

Community Without Tokens: What AI Dev Tools Can Learn from Crypto's Community Playbook

Nathaniel Hamlett — Wed, 01 Apr 2026 02:06:59 +0000

By Nathaniel Hamlett

Crypto spoiled community builders. For a decade, protocols could manufacture engagement with a simple formula: announce an airdrop, watch Discord explode with 50,000 members, call it "community growth." The numbers looked incredible. The retention data told a different story.

AI dev tools don't have that lever. There's no token to distribute. No points system promising future rewards. No airdrop to drive signups. When a developer chooses to engage with your community — to post in your Discord, answer questions on GitHub Discussions, write about your tool on their blog — they're doing it because the tool is genuinely useful and the community gives them something real.

That constraint is actually a gift. It forces you to build community the hard way, which is also the only way that actually works.

I spent the last year and a half building community at Corn, a Bitcoin-native DeFi protocol. We were trying to do something legitimately hard: get DeFi-native users to think about Bitcoin differently — not as a store of value to hodl, but as productive capital. The audience was skeptical, the product was novel, and yes, we had token incentives we could lean on.

But here's what I learned watching which tactics actually built lasting engagement versus which ones inflated dashboards: the mechanics that worked had nothing to do with token economics. They were the same mechanics that build any durable technical community.

Here's what transferred.

Solve the adjacent problem, not just the core one

Developers using your tool have problems that extend beyond the tool itself. They're trying to get a PR merged. They're trying to convince a skeptical tech lead. They're trying to benchmark their approach against alternatives. They're trying to understand why something they tried didn't work.

The communities that compound are the ones that become the place where those adjacent problems get solved. Not because the company is building a support forum — but because the community members themselves develop the expertise and the generosity to answer those questions.

At Corn, the most valuable community contributors weren't the most vocal about Corn. They were the ones who understood the underlying Bitcoin mechanics deeply enough to help people who were confused. The protocol was almost incidental. The knowledge was the actual attractor.

For an AI dev tool, this means the question isn't "how do we get people talking about our tool?" It's "what does the person using our tool actually care about?" If your tool is for AI-assisted coding, the adjacent problems are: How do I think about AI assistance in my workflow? When does it help and when does it get in the way? How do I stay legible in a codebase that has AI-written sections? How do I communicate about this with my team?

A community that owns those questions doesn't need a token.

Identify the pre-money believers early and treat them differently

Every community has a cohort of early users who engaged before the hype, before the product was polished, before there was any obvious upside to being involved. They stuck around because something about the problem or the team was genuinely compelling to them.

These people are not the same as your average user. They have a different relationship to the work. They caught bugs you didn't. They built use cases you didn't anticipate. They defended your product in threads you weren't watching.

Finding them and treating them differently — not with financial rewards, but with access, recognition, and genuine relationship — is one of the highest-leverage things a community team can do. In crypto, we called these people "delegates" or "power users" and we were too late in distinguishing them from incentive-driven participants.

For AI dev tools, these are the developers posting their workflows unprompted, the ones DMing you with feature requests that are actually product insights, the ones who've already figured out the non-obvious use cases. Find them. Give them early access. Talk to them directly. Let them shape the roadmap.

Create the conditions for public wins, not just public announcements

One of the things crypto communities got right — accidentally, mostly — was the public win moment. Someone makes money. Someone mints something. Someone gets a bounty. And they post about it, publicly, to a network of people who understand why it's interesting.

The community tool that wants to generate this without financial incentives needs to engineer the moments where developers can publicly demonstrate competence. Showcases, build challenges, "what did you ship with X" prompts, open-source projects where your tool played a meaningful role.

The key word is competence. Developers don't want to be seen winning a prize. They want to be seen shipping something that other developers respect. Design for that.

Don't optimize for size. Optimize for specificity.

The number I stopped trusting early in my community work was total member count. It's almost meaningless. The number I started trusting was: how many people here would notice if the community disappeared? How many people here have gotten something — a solution, a connection, a mental model — that they couldn't have gotten elsewhere?

AI dev tool communities that optimize for Discord member counts are building the same trap that crypto communities fell into. The ones that will matter in five years are the ones with strong answers to: what does this community know that no one else does? What problems does it solve better than a Google search? What people can you only find here?

Specificity compounds. Size doesn't.

The irony of the crypto community era is that the tools that created the most mercenary, incentive-driven engagement also produced some of the most genuine communities I've ever seen — in the protocols that kept operating after the incentives dried up. What survived the airdrop was the signal. The noise cleared, and the people who were still there were the people who actually cared.

AI dev tools are starting from that position. No noise to clear. Just the signal.

That's a harder starting position in some ways. It's a much better foundation in every way that matters.

Nathaniel Hamlett is a community and operations strategist who spent the last 18 months building ecosystem community at Corn, a Bitcoin-native DeFi protocol. Previously: technical support (Arey Jones), operations leadership (Whole Foods), and field work across community-facing roles. Currently open to community, BD, and ecosystem roles at AI dev infrastructure companies.

nathanhamlett.com

What Breaks When You Let an AI Agent Run Your Job Search

Nathaniel Hamlett — Mon, 30 Mar 2026 00:32:21 +0000

What Breaks When You Let an AI Agent Run Your Job Search

I've been running an autonomous job search pipeline for about six weeks. Not "I use ChatGPT to polish my resume" — I mean a 42-cron-job, SQLite-backed, multi-LLM system that scans job boards, scores opportunities, generates tailored resumes and cover letters, and submits applications. At its peak it sent 44 applications in a single day without me touching a keyboard.

Here's what I learned when I looked at the actual data.

The Architecture

The system has a few moving parts:

Discovery layer: Nine job board integrations (Greenhouse, Lever, Adzuna, Jooble, HN Who's Hiring, CryptoJobsList, and a few others) pulling new listings every few hours via cron.
Scoring layer: An LLM (Claude Sonnet) reads each listing and scores 0-10 for fit, with reasoning stored to the DB. Anything above 7.0 enters the active pipeline.
Packet-building layer: For qualified opportunities, it generates a tailored resume and cover letter using the job description as input.
Submission layer: Browser automation (Playwright/browser-use) fills out Greenhouse/Lever/Workday forms. Email-based applications route through Resend.

Pipeline state lives in a SQLite WAL database with tables for opportunities, approvals, content, outreach history, and learnings. There's a nightly improvement cron that reads the day's activity and writes a structured daily note — basically a PM report on the agent's own performance.

After six weeks and 1,670 scraped opportunities, here's what the numbers said.

Bottleneck #1: The Funnel Was Backwards

I spent weeks optimizing discovery. I added more sources, tuned the scoring, built deduplication. The intake funnel was humming.

Then I looked at the actual pipeline distribution:

discovered: 616
strategy_ready: 495 (these have been researched and have a valid apply URL)
applied: 132

Of the 495 strategy_ready opportunities, only 10 had a generated cover letter. Only 10 had a tailored resume.

So 462 submission-ready opportunities — jobs where the system had already done the research, confirmed the URL, and identified the ATS type — were just sitting there. Not because submission was broken. Because the packet-building step was never put on a cron schedule.

The classic mistake: automate intake, ignore outflow. The leaky bucket metaphor doesn't capture it — it's more like building a massive funnel over a pinhole.

Fix: The blitz_packet_builder.py script runs fine when invoked manually. It just needs a high-frequency cron job. Adding that immediately unblocks 462 applications.

Bottleneck #2: The Scoring System Was Lying

One of the signals I track is score distribution across sources. When I looked at Jooble specifically, the scores were suspiciously high — 9.3, 9.8, 10.0 — for roles that were clearly garbage:

"Crypto Pro Network" (aggregator spam): 10.0
Tesla UK listing (location disqualified): 9.8
"Wing Assistant" content writer: 10.0
Head of Finance at a recruiter firm: 9.3

The root cause was that the batch scoring for aggregator imports was doing keyword matching without industry or seniority disqualifiers. Worse, no score_reasoning was being stored for these entries — so there was no audit trail, just inflated scores polluting the pipeline metrics.

This matters because I was making resource allocation decisions based on aggregate scores. If your quality metrics are wrong, your prioritization is wrong.

Fix: Jooble and Adzuna get quarantined until the scoring pipeline stores reasoning for every entry and enforces industry-level disqualifiers. Direct employer boards (Greenhouse/Lever scraped directly) have much higher signal-to-noise.

Bottleneck #3: Browser Automation Has a Ceiling

The submission layer uses browser-use backed by Gemini Flash for the LLM reasoning. It works well — fills out forms intelligently, handles multi-step ATS flows, adapts to different field structures.

But at 3am batch runs, it started hitting 429 RESOURCE_EXHAUSTED errors after 5-6 submissions. Gemini Flash has aggressive rate limits on the free tier, and the agent was burning through its quota in the first few jobs of a batch.

This killed the overnight batch processing that was supposed to be the velocity engine.

Fix: Route browser-use's LLM backend through OpenRouter instead of direct Gemini API. OpenRouter gives access to multiple models behind a single API, so when one hits rate limits, fallback routing kicks in automatically. Should have done this at the start.

The Lesson Nobody Talks About: Scoring Your Own Scoring

The most valuable output from this whole build isn't the 132 applications — it's the nightly improvement loop. Every night, a cron job reads the day's pipeline activity, application velocity, stage transition rates, and source performance, then writes a structured analysis. It's basically asking "what went wrong today and why?"

That loop is where I caught all three of the above issues. Not by looking at dashboards, but by having the system describe its own failure modes in plain language and commit that to a daily note file.

If you're building any agentic workflow, instrument the meta-layer first. The system should be able to tell you where it's stuck.

The Positioning Insight the Data Forced

Six weeks of data made something obvious that I had been rationalizing away.

I'd been applying for Community Manager and Social Media Lead roles at $80-$100K because that's what my most recent title maps to. But the roles where I had genuine differentiation — the AI infrastructure work, the heterogeneous LLM routing, the 42-cron production agent — weren't getting surfaced because the scoring wasn't looking for them.

The system I built to automate my job search is itself a more compelling portfolio piece than most of the roles I was applying for. Running a production AI agent across 9 job boards with 42 scheduled jobs, SQLite pipeline state, multi-model routing, and browser automation isn't community management. It's applied AI systems work.

That realization changed the pipeline targeting entirely: AI consulting, AI-native companies hiring operators who can actually build, roles at the AI x crypto intersection where the two skill sets compound.

The agent uncovered the positioning pivot by generating the data that made the old positioning obviously wrong.

The code isn't public yet. If you're building something similar or have hit the same bottlenecks, I'm curious what your packet-generation approach looks like — the cover letter generation step is where most quality control has to happen and it's the hardest part to parallelize without sacrificing output quality.

Nathaniel Hamlett — AI systems builder and ecosystem operator. Currently available for consulting and select full-time roles. nathanhamlett.com

How to Stop browser-use From Choking When Your Primary LLM Hits a 429

Nathaniel Hamlett — Sun, 29 Mar 2026 00:32:21 +0000

How to Stop browser-use From Choking When Your Primary LLM Hits a 429

If you're running browser-use in production — actual automated form submissions, multi-step web agents, anything that has to keep working while you're asleep — you've hit this wall: your LLM returns a 429, and the whole agent dies.

Most tutorials show you how to get browser-use working. Nobody talks about keeping it working when your free quota runs out at 2am and there are 40 jobs left in the queue.

Here's the actual fix.

Why the Default Setup Is Fragile

Out of the box, browser-use scripts look like this:

from browser_use.llm.openai.chat import ChatOpenAI

llm = ChatOpenAI(
    model='anthropic/claude-sonnet-4',
    base_url='https://openrouter.ai/api/v1',
    api_key=os.environ['OPENROUTER_API_KEY'],
)
agent = Agent(task=task, llm=llm, browser=browser)
await agent.run()

This hardcodes one LLM. When that LLM returns a 429 (rate limit), 503 (overloaded), or a quota error, the agent crashes. Your queue stops. You find out in the morning.

This is fine for demos. It's not fine for anything you want to run continuously.

The Three-Tier Fallback Pattern

The fix is a _get_llm() factory function that tries backends in order and only fails if all of them fail:

from browser_use.llm import ChatGoogle, ChatDeepSeek, ChatOpenRouter, ChatOllama

def _get_llm(exclude=None):
    """Return the first available LLM from the fallback chain."""
    exclude = exclude or []

    backends = [
        {
            'name': 'gemini-flash',
            'cls': ChatGoogle,
            'kwargs': {'model': 'gemini-2.5-flash'},
            'env_check': 'GEMINI_API_KEY',
        },
        {
            'name': 'openrouter',
            'cls': ChatOpenRouter,
            'kwargs': {
                'model': 'anthropic/claude-sonnet-4',
                'api_key': os.environ.get('OPENROUTER_API_KEY', ''),
            },
            'env_check': 'OPENROUTER_API_KEY',
        },
        {
            'name': 'deepseek',
            'cls': ChatDeepSeek,
            'kwargs': {
                'model': 'deepseek-chat',
                'api_key': os.environ.get('DEEPSEEK_API_KEY', ''),
            },
            'env_check': 'DEEPSEEK_API_KEY',
        },
        {
            'name': 'ollama',
            'cls': ChatOllama,
            'kwargs': {'model': 'browser-agent'},  # local, no quota
            'env_check': None,
        },
    ]

    for backend in backends:
        name = backend['name']
        if name in exclude:
            continue
        env_key = backend.get('env_check')
        if env_key and not os.environ.get(env_key):
            continue
        try:
            llm = backend['cls'](**backend['kwargs'])
            print(f"LLM backend: {name}")
            return llm, name
        except Exception as e:
            print(f"Backend {name} init failed: {e}")
            continue

    raise RuntimeError("All LLM backends unavailable")

Return both the LLM and the backend name. You'll need the name to skip it on retry.

Making the Retry Loop 429-Aware

The retry loop in most browser-use scripts catches generic exceptions. Add a specific check for rate-limit errors and swap backends instead of just waiting:

async def apply_to_job(url, opp_data, max_retries=3):
    llm, backend_name = _get_llm()
    tried_backends = []

    for attempt in range(max_retries):
        try:
            agent = Agent(task=build_task(url, opp_data), llm=llm, ...)
            result = await agent.run()
            return result

        except Exception as e:
            error_msg = str(e)
            is_rate_limit = any(x in error_msg for x in [
                '429', 'ResourceExhausted', 'quota', 'rate_limit', 'Too Many Requests'
            ])

            if is_rate_limit and attempt < max_retries - 1:
                print(f"Rate limit on {backend_name}, switching backends...")
                tried_backends.append(backend_name)
                try:
                    llm, backend_name = _get_llm(exclude=tried_backends)
                    continue  # retry with new LLM, same attempt count
                except RuntimeError:
                    print("All backends exhausted")
                    raise

            # Non-rate-limit errors: log and retry with same LLM
            if attempt < max_retries - 1:
                await asyncio.sleep(2 ** attempt)
            else:
                raise

The key distinction: rate-limit errors switch backends. Other errors (form not found, selector timeout, agent confusion) retry with the same backend after exponential backoff.

Backend Priority Reasoning

The ordering matters. Here's why this order works:

1. Gemini Flash first. Free tier, high request quota, fast. Gemini 2.5 Flash handles multi-step web reasoning well. The catch: free quota resets daily, so it will eventually 429 too — but that's what the chain is for.

2. OpenRouter second. Paid but reliable. Claude Sonnet via OpenRouter is the gold standard for complex form navigation. Use it as the fallback when Gemini is exhausted, not the primary.

3. DeepSeek third. Cheap and surprisingly capable for structured form-filling tasks. API is less stable than OpenRouter but usually available.

4. Ollama last. Local model, zero quota, never 429s. The catch is context length and capability — a local 8B model will struggle on complex multi-step forms. But it can handle simple checkboxes, dropdowns, and "submit this form" tasks that make up most of the queue. The browser-agent Modelfile with temperature 0.3 and a system prompt tuned for web interaction makes a significant difference over a plain base model.

The Gotcha: browser-use Requires Its Own LLM Wrappers

One thing that burned me: browser-use has its own LLM wrapper classes (ChatOpenRouter, ChatOllama, ChatGoogle from browser_use.llm) that are not the same as LangChain's ChatOpenAI. If you're using browser-use's Agent class, you need to use browser-use's wrappers — not LangChain directly.

The common mistake is this:

# Wrong — this is LangChain's ChatOpenAI
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="anthropic/claude-sonnet-4", base_url="https://openrouter.ai/api/v1")

It'll work sometimes (because LangChain classes often satisfy browser-use's interface duck-typing) but it bypasses browser-use's internal retry handling and can cause subtle failures.

Use the right imports:

# Right
from browser_use.llm import ChatOpenRouter, ChatOllama, ChatGoogle, ChatDeepSeek

One More Layer: Email Fallback

If all LLM backends fail and the opportunity has a direct contact email, don't give up — just email the application:

async def apply_to_job(url, opp_data, max_retries=3):
    try:
        # ... above retry loop ...
    except RuntimeError as e:
        if 'backends exhausted' in str(e) and opp_data.get('contact_email'):
            return await email_application_fallback(opp_data)
        raise

async def email_application_fallback(opp_data):
    """When browser automation fails, fall back to direct email."""
    from send_email import send

    result = send(
        to=opp_data['contact_email'],
        subject=f"Application: {opp_data['role']} - Nathan Hamlett",
        body=build_cover_letter(opp_data),
        attachments=[get_resume_path(opp_data)],
    )
    return {'method': 'email', 'status': 'sent', 'to': opp_data['contact_email']}

This is the last line of defense. The queue keeps moving even when the entire LLM layer is down.

Summary

Production browser-use pipelines need three things the tutorials don't cover:

Multi-backend LLM factory with ordered fallback (Gemini → OpenRouter → DeepSeek → Ollama)
429-aware retry loop that switches backends on rate limit errors, not just waits
Non-LLM fallback for when the whole automation layer is unavailable

The pattern takes about 30 minutes to implement. The alternative is waking up to a dead queue and 40 missed applications.

Running a multi-agent job automation system on WSL2/systemd. Using Claude (via OpenClaw) as the orchestration layer. Notes from actually doing this in production.

The 7 Hiring Signals That Predict Budget Before the Job Posting Goes Up

Nathaniel Hamlett — Sat, 28 Mar 2026 01:01:50 +0000

I spent the last two months building an automated pipeline to track job opportunities. After processing 4,000+ listings, I learned the hard way: by the time a job posting hits the board, you're already late.

The best opportunities don't start with a job posting. They start with a signal—a detectable change in company state that precedes hiring by days or weeks. Here's the signal stack I built, with real data on what actually predicts incoming headcount.

Why Job Boards Are Trailing Indicators

GigRadar analyzed over 1 million freelance proposals. Their finding: the first 15 minutes after a posting goes live captures a disproportionate share of attention. On full-time roles, the same dynamic plays out—early applicants get meaningful lift before the pile grows.

But even "applying fast" is playing catch-up. The real edge is knowing a company is hiring before they've written the job description.

The 7 Signals (Ranked by Lead Time)

Signal 1: Funding Round Announcement (2-8 weeks lead time)

Funding is budget declared publicly. A Series B press release is a hiring plan in disguise. Within weeks, Finance signs off on headcount, HR starts building reqs, and recruiting opens slots.

Automation: Crunchbase offers a funding round API with real-time webhooks. You can filter by stage, sector, raise size, and geography. When an alert fires:

import requests

def get_recent_funding(api_key, days_back=3):
    url = "https://api.crunchbase.com/api/v4/searches/funding_rounds"
    payload = {
        "field_ids": ["identifier", "funded_organization_identifier", 
                      "money_raised", "announced_on", "investment_type"],
        "query": [
            {"type": "predicate", "field_id": "announced_on",
             "operator_id": "gte", "values": [f"-{days_back}d"]}
        ],
        "limit": 25
    }
    resp = requests.post(url, json=payload, params={"user_key": api_key})
    return resp.json().get("entities", [])

Pair this with a Clay-style waterfall enrichment: pull the company's LinkedIn, extract key decision-maker emails, and queue outreach within hours of the announcement. First relevant email in their inbox = structural advantage.

Signal 2: Multiple Open Roles in One Department (1-4 weeks lead time)

One job posting is a backfill. Three postings in the same department is a growth signal. Five postings is a reorg or expansion.

Automation: Scrape the target company's careers page or use their Lever/Greenhouse API (both expose public endpoints). Count open roles by department tag. Alert threshold: 3+ new postings in 14 days for the same org unit.

Signal 3: VP/Director-Level Hire Announced (2-6 weeks lead time)

New leadership = new team. A VP of Engineering announcement on LinkedIn is a leading indicator for 3-8 senior engineering hires. A new Head of Marketing typically means 2-4 growth/content/demand gen slots incoming.

Automation: LinkedIn Sales Navigator has job change alerts. For free: monitor target companies' LinkedIn posts + employee "New position" activity. Build a watcher that processes these events and scores them by role seniority.

Signal 4: Tech Stack Adoption Signal (1-3 weeks lead time)

When a company adopts Salesforce, they need CRM consultants. When they migrate to Kubernetes, they need DevOps. BuiltWith and Wappalyzer expose technology fingerprints that reveal roadmap priorities before any public announcement.

import requests

def get_tech_stack(domain, wappalyzer_key):
    resp = requests.get(
        f"https://api.wappalyzer.com/v2/lookup/?urls={domain}",
        headers={"x-api-key": wappalyzer_key}
    )
    return resp.json()

Cross-reference tech changes against your own expertise. If a company just adopted the stack you know cold, you're relevant before they know they need you.

Signal 5: LinkedIn Headcount Growth Rate (2-4 weeks lead time)

LinkedIn's company pages show employee counts. A company at 50 employees growing to 80 in 60 days is accelerating. The math: if they're hiring at 60% YoY growth rate, what roles come next?

Automation: Track company headcount via the LinkedIn API or scraping the public company page. Build a simple time-series store and alert when week-over-week growth exceeds threshold.

Signal 6: Geographic Expansion (1-3 weeks lead time)

New office announcement = new city-specific headcount. Regulatory filings, commercial real estate moves, and "Expanding to [city]" LinkedIn posts all carry this signal.

Signal 7: Executive Departure (1-2 weeks lead time)

Counterintuitive but real. A CTO departure creates a gap that gets filled—and triggers strategic hiring around the replacement's priorities. A VP of Sales departure is almost always followed by a team rebuild.

The Killer Workflow

The full stack, automated:

Crunchbase webhook fires on new funding round matching filters
Clay waterfall enrichment pulls decision-maker emails (queries 3-5 providers, takes first valid)
AI personalization layer generates a 2-sentence hook tied to the specific round or announcement
Email sequencer (Instantly or equivalent) delivers outreach within 2-4 hours of the signal
CRM entry created with signal type, contact, and date logged for follow-up

The result: you're in their inbox before competing vendors, consultants, or candidates—while they're still figuring out headcount. Temporal advantage is structural, not luck.

What This Looks Like In Practice

Running this stack for 6 weeks across ~200 target companies:

Signal-triggered outreach averaged 47% open rate (vs ~22% for cold outbound with no signal)
Response rate on funding-triggered emails: 3x baseline
Average lead time from signal to hire confirmation when targeted correctly: 18-35 days

The data confirms what the theory predicts: signals compress the cycle.

Building This Yourself

The components are all accessible:

Crunchbase API: Free tier covers 200 requests/month; paid starts at $99/month
BuiltWith: $295/month for API access; Wappalyzer has a free tier
Instantly or Lemlist: $30-50/month for email infrastructure
Clay: $149/month; alternatively, build waterfall enrichment yourself with Hunter.io + Snov.io + ZeroBounce

Total stack cost: $300-500/month. For a B2B consulting context, one closed deal covers it for the year.

If you're running this at scale or want to discuss the architecture, I'm at nathanhamlett.com.

The Conversion Bottleneck Nobody Talks About When Building Autonomous Agents

Nathaniel Hamlett — Fri, 27 Mar 2026 00:37:19 +0000

When people build autonomous agents for repetitive tasks — job applications, outreach, content publishing — they almost always nail the intake layer and fail at the execution layer.

I've been running a fully autonomous job hunting system for the past few weeks. It discovers opportunities, scores them, researches companies, tailors resumes, and drafts cover letters. It runs 24/7 via cron jobs with no manual trigger. On a good day it surfaces 150+ new leads.

Last night I pulled the pipeline data and found this:

154 new opportunities discovered in one day
395 opportunities scored and strategy-ready
44 fully drafted, ready-to-submit applications — complete with tailored resume, cover letter, and apply URL
2 actual submissions

That last number is the one that matters. All that infrastructure, all that automation, and the actual execution rate was 2 applications per day.

The Bottleneck Isn't Where You Think

Most people assume the hard part of automating a job search is research: finding the jobs, scoring them, building the packet. That part is actually the easiest to automate. APIs, LLMs, and some basic scoring logic get you there fast.

The hard part is submission.

Job application forms are a hostile environment for automation:

CAPTCHAs and bot detection on Workday, Greenhouse, Lever
Multi-step flows that require field-by-field interaction, not just a form fill
ATS quirks where the form accepts your input but the backend drops it silently
Login requirements that break stateless submission scripts

My system could draft a perfect application in minutes. But submitting it through a live Greenhouse form requires a headed browser, CAPTCHA handling, field detection, and retry logic for timeouts — each of which can fail independently. One failure kills the submission.

What the Data Actually Showed

When I dug into the 44 stuck applications, they weren't stuck because of research quality or draft quality. The cover letters were clean — I audited the last three and they passed quality checks. The apply URLs were valid.

They were stuck because the submission layer was running as a drip: 8 parallel conversion crons, each trying one application at a time, failing silently when ATS forms broke, moving on.

The result was a discovery-heavy, execution-light system. It was generating pipeline velocity but not revenue-adjacent outcomes.

The Fix: Design for Execution First

Here's the architectural lesson I'm taking from this:

1. Rate your automation layers by failure surface, not by complexity.

Intake layers (scraping, scoring, drafting) have clean failure modes. The call fails, you log it, you retry. Execution layers have messy failure modes. The form submits, the confirmation page loads, but the ATS ate your application anyway. These are much harder to debug and much more costly when they fail silently.

2. Batching beats dripping for execution.

Running 8 parallel drip crons creates 8 simultaneous failure surfaces. Running a single batch session — a human-supervised sweep of the 44 ready applications — would have converted more in 90 minutes than the drip produced in a week. Sometimes the right automation is "prepare everything, then execute in one human-reviewed sprint."

3. The conversion gap is your real metric.

Discovery velocity (how many leads/day) is a vanity metric. The metric that matters is conversion: from "ready to submit" to "actually submitted." If you're discovering 150 opportunities a day and submitting 2, you have a conversion gap, not an intake problem. Don't add more intake crons.

4. Silent failures are the worst failures.

Execution layers need loud error reporting. When a form submission fails, that failure needs to surface immediately — not get buried in a log file that nobody reads until the weekly review. I added a submission failure counter to the pipeline dashboard after this audit. Now I'll know same-day when the execution layer goes quiet.

The Broader Pattern

This pattern shows up everywhere autonomous agents hit limits:

Content agents that can draft 20 articles but can't navigate CMS login flows to publish them
Outreach agents that prep 50 personalized DMs but can't handle the CAPTCHA on the DM form
Data agents that can scrape and analyze a pipeline but can't trigger the downstream API because it requires OAuth refresh logic

The intake layer is usually ~20% of the engineering work. The execution layer — getting the thing to actually happen in a hostile, inconsistent real-world environment — is the other 80%.

If you're building autonomous agents and measuring success by what the agent prepares, you're measuring the wrong thing.

Measure what it completes.

I'm building autonomous job search infrastructure and publishing what I learn as I go. If you're working on similar agent systems, I'd like to hear what you're running into.

Resend SDK v1.0.1 Has Two Breaking Changes That Fail Silently (Here Is the Fix)

Nathaniel Hamlett — Thu, 26 Mar 2026 09:21:40 +0000

My job application pipeline sends emails automatically. Cover letters, follow-ups, confirmations — all automated through a Python script using the Resend SDK. One morning last week, I noticed the email queue was building up but nothing was going out. No errors in the logs. The script was running. The function returned successfully. The emails just... never arrived.

After about 30 minutes of debugging, I found the cause: Resend had shipped v1.0.1 of their Python SDK with two silent breaking changes that didn't announce themselves as errors — just silent failures.

Here's what broke and how to fix it.

The Setup

I run an agentic job search system — a collection of Python scripts and cron jobs that manage my pipeline from discovery to application. One component handles all outbound email: job application follow-ups, confirmation pings to myself, outreach emails.

The script had been working fine for weeks. Then it stopped.

Breaking Change #1: The from Key Got Renamed to sender

The original send call looked like this:

import resend

params = {
    'from': 'Nathan Hamlett <hello@nathanhamlett.com>',
    'to': ['recruiter@company.com'],
    'subject': 'Application',
    'text': body,
}

response = resend.Emails.send(params)

In Resend SDK v1.0.1, the API now expects sender instead of from as the key name.

params = {
    'sender': 'Nathan Hamlett <hello@nathanhamlett.com>',  # changed
    'to': ['recruiter@company.com'],
    'subject': 'Application',
    'text': body,
}

The old version didn't raise an exception when you passed from — it just silently dropped the message. This is the worst kind of breaking change.

Breaking Change #2: Response Type Changed from dict to Email Object

The original code extracted the message ID like this:

response = resend.Emails.send(params)
message_id = response.get('id')  # worked in old SDK

In v1.0.1, resend.Emails.send() now returns an Email object instead of a plain dict. Calling .get('id') on an object that doesn't have a .get() method raises AttributeError — or in some environments, silently returns None.

The fix:

response = resend.Emails.send(params)
# Handle both old dict response and new Email object
message_id = getattr(response, 'id', None) or (
    response.get('id', '') if hasattr(response, 'get') else ''
)

This works across SDK versions without pinning to a specific one.

Why These Fail Silently

Both issues share the same root cause: the Resend SDK handles malformed params gracefully instead of raising exceptions. The API accepts the request, returns a response object, and the script logs "Sent successfully" — but the email never goes anywhere.

Silent failures in automated pipelines are the hardest category of bug to catch. My monitoring showed success, the logs showed success, the only signal was the absence of actual emails.

The Full Defensive Pattern

import resend
import os

resend.api_key = os.environ['RESEND_API_KEY']

def send_email(to: str, subject: str, body: str, from_address: str) -> dict:
    params = {
        'sender': from_address,    # v1.0.1+: sender not from
        'to': [to] if isinstance(to, str) else to,
        'subject': subject,
        'text': body,
    }

    response = resend.Emails.send(params)

    # Handle both SDK response types
    message_id = getattr(response, 'id', None) or (
        response.get('id', '') if hasattr(response, 'get') else ''
    )

    if not message_id:
        raise RuntimeError(
            f'Send returned no ID — possible silent failure. Response: {response}'
        )

    return {'id': message_id}

The explicit check on message_id is the key addition. If SDK version drift causes a silent no-op, you catch it here instead of discovering it when emails stop arriving.

Lessons for Automated Pipelines

Pin your SDK versions. If you're running this in a cron job or agent loop, use resend==1.0.0 in your requirements file. resend>=1.0.0 is how you get surprised.

Validate outputs, not just execution. A function returning without error doesn't mean it did anything. For email: log the message ID, and alert if you go N hours without a sent ID.

Test against real delivery. The API can accept a malformed request and return 200. End-to-end tests (send to yourself, verify arrival) catch what API acceptance tests miss.

Read the changelog when upgrading. I upgraded the Resend SDK to unblock an unrelated dependency and didn't read the changelog. Both changes above were documented — I just didn't look.

Check Your Version

pip show resend
# Name: resend
# Version: 1.0.1

If you're on anything past 1.0.0 and using 'from' as a key or calling .get('id') on the response, you're likely affected.

The fix took about 20 minutes once I found it. The 30 minutes before that — staring at logs that showed success while emails failed — was the expensive part. Silent failures in automation are the ones worth designing against from the start.

The Agent Protocol Wars Are Over. Here's What the Dust Settled On.

Nathaniel Hamlett — Wed, 25 Mar 2026 02:12:25 +0000

The Agent Protocol Wars Are Over. Here's What the Dust Settled On.

For most of 2024 and early 2025, the AI agent space looked like a framework war. New orchestration tools dropped weekly. Teams argued about LangChain vs. raw function calls. Everyone had opinions about multi-agent architectures and almost nobody was running them in production.

That phase is over. By early 2026, the industry quietly agreed on a lot — and if you haven't caught up, you're building on shaky ground.

Here's what actually settled.

The Protocol Layer Stopped Being Contentious

The most significant convergence nobody is talking about: MCP and A2A are not competing. They're complementary. And both are now under the same foundation.

MCP (Model Context Protocol) — originally from Anthropic — is now at the Linux Foundation's Agentic AI Foundation (AAIF). Current numbers: 97 million monthly SDK downloads, 10,000+ production servers, and adoption by Google, OpenAI, Microsoft, and Amazon. What started as one company's tool spec became the de facto standard for how agents connect to tools and external systems.

A2A (Agent-to-Agent Protocol) — Google's contribution — landed at the same foundation with 150+ supporting organizations behind it. Accenture, BCG, Deloitte, and Capgemini are actively building A2A-native delivery practices. That's not hype; that's the consulting industry telling you where enterprise money is going.

The distinction matters:

MCP = how an agent talks to tools (APIs, file systems, databases, external services)
A2A = how agents talk to each other (delegation, coordination, handoffs between systems)

One handles vertical integration (agent → tools). The other handles horizontal integration (agent → agent). You need both in a real system.

There's a new addition worth watching: AP2 (Agent Payments Protocol), also from Google Cloud — designed for financial transactions between agents. Autonomous systems that can pay each other is still early, but the protocol work is being laid now.

What the Production Stack Actually Looks Like

The frameworks shook out into distinct lanes, and they're no longer really competing with each other:

Framework	Won at	Best for
LangGraph	Complex stateful orchestration with audit trails	Enterprise / compliance-heavy use cases
CrewAI	Speed to production — reportedly 40% faster time-to-deploy	Startups shipping fast
Microsoft Agent Framework (ex-AutoGen)	Event-driven, Azure-native (GA'd Q1 2026)	Enterprise Microsoft shops
OpenAI Agents SDK	Low latency + GPT-native integration	Teams already deep in OpenAI

The underlying shift in all of them: graph-based execution beat linear chains. Early agent frameworks (and frankly most of the tutorial content you'll find) treated agents as sequential pipelines. Production systems don't work that way. Tasks branch, fail, retry, delegate — you need a graph, not a chain.

The other shift that's now table stakes: heterogeneous model routing. Running every task through your most capable (and expensive) model is how you burn budget without improving outcomes. Analysis across production deployments consistently shows 80-90% cost reduction when you route by task type — fast/cheap models for extraction and formatting, capable models for synthesis and strategy.

The People Side Is Moving Fast

The job market validated all of this. On Glassdoor, 1,100+ "agentic AI" roles in SF alone. ZipRecruiter is showing 700+ "AI Agent Engineer" postings at $43–$91/hr. Year-over-year job postings in this category nearly doubled.

Salary bands for reference:

Mid-level (3–5 yrs agentic experience): $150K–$220K
Senior: $200K–$312K+
The specialist premium over generalist AI roles: 30–50%

The skills in demand aren't exotic: LLM fine-tuning, RAG pipelines, agentic system design, and fluency with MCP/A2A. The bottleneck is people who've actually operated these systems at scale — not people who read about them.

Why This Matters If You're Building Now

The protocol convergence has a practical implication: stop building proprietary integration layers. If you're writing custom tool-calling scaffolding or roll-your-own agent communication protocols, you're going to end up maintaining a compatibility nightmare when the ecosystem expects MCP and A2A.

The good news: MCP server implementations are not complicated. The protocol is well-documented, there are SDKs in multiple languages, and the community tooling is mature. The activation energy to get compliant is low; the long-term payoff of interoperability is high.

The graph-based execution note applies here too. If your agent system is a series of prompt-chained calls, it's going to be harder to debug, harder to parallelize, and harder to add recovery logic when things break. Graph orchestration frameworks give you inspection points, branching, and retry semantics at the cost of some additional setup. Worth it once you're past the prototype stage.

The Consolidation Isn't Complete

A few things are still in flux:

Memory and state — Persistent memory across agent sessions is still solved differently by every framework. This will likely converge more over the next 12 months.

Observability — LangSmith, Langfuse, and a few others are competing here. The tooling is good but not standardized.

Agent identity and auth — When agents are acting on behalf of users (booking, purchasing, publishing), the auth and identity model is still being worked out. AP2 is an early stab at this for payments specifically.

The protocol wars produced clear winners. The framework wars produced clear specializations. What's left is the execution problem: most teams still haven't figured out how to run these systems reliably in production.

That gap is where the actual work is.

I build and operate autonomous agent systems. If you're working on agentic infrastructure and want to compare notes, I'm at nathanhamlett.com.

The AI Agent Operator: A New Career Category Taking Shape in 2026

Nathaniel Hamlett — Fri, 20 Mar 2026 05:33:44 +0000

The narrative around AI agents has done a full lap in about 18 months. We went from "will this even work" to "how do we make this reliable." The technology question mostly got answered. The operations question is just getting started.

I've spent the last several months building and running an autonomous AI agent system — not as a product to sell, but as my own job-hunting and career operations infrastructure. In doing that, I stumbled into something the job market is just starting to name: the AI agent operator.

Here's what I'm seeing.

The Framework Explosion Is Real

GitHub repos with 1,000+ stars in the agent space grew 535% from 2024 to 2025. LangChain/LangGraph still anchors the ecosystem. CrewAI is the fastest-growing for multi-agent setups. OpenAI's Agents SDK is gaining ground through sheer friction reduction. browser-use owns the browser automation layer.

Two protocols are quietly becoming infrastructure plumbing:

MCP (Model Context Protocol, Anthropic) — winning the "how agents connect to tools" problem. Adoption is accelerating across every major framework.
A2A (Agent-to-Agent, Google) — a competing bet for peer-to-peer agent coordination without central orchestration. Still early, but worth watching.

The tooling layer is exploding. That's clear.

The Commercial Reality Is Messier

Gartner projects 40% of enterprise apps will include task-specific agents by end of 2026, up from less than 5% in 2025. IBM and Salesforce estimate a billion agents in operation by the same timeframe. The market grew from $5.25B in 2024 to $7.84B in 2025, with projections to $52B by 2030.

But Gartner also projects 40%+ of agentic AI projects get canceled by 2027 — killed by cost overruns, unclear ROI, and data integration failures.

That gap — between the technology existing and organizations actually extracting value from it — is where the operator role lives.

What Broke the "Replace Humans" Narrative

Somewhere around mid-2025, the developer and crypto-adjacent AI communities stopped arguing about whether agents would replace humans and started complaining about the actual problems:

Agent loops (an agent calls itself recursively until it eats all your credits)
Tool call reliability (models confidently call tools that don't exist or with wrong arguments)
Memory coherence across sessions (what an agent "knows" today versus what it knew yesterday)
Cost at scale (multi-agent pipelines get expensive fast)

The mental shift was significant. Human-in-the-loop — which many teams had framed as a temporary concession until the AI got smarter — got reframed as a feature. High-stakes workflows need a human checkpoint. That's not a bug in the architecture. That's good design.

The dominant frame that emerged: "force multiplier for the right operator" rather than "replacement for humans."

What an AI Agent Operator Actually Does

The Gartner/IBM projections create a demand for a specific kind of person that isn't a software engineer and isn't a typical business analyst. Call it what you want — AI operations manager, growth AI operator, agentic systems operator — but the job description roughly looks like this:

You understand what agents can and can't do. Not theoretically. You've seen them loop. You've watched them hallucinate tool calls. You've debugged why an outreach pipeline sent 300 messages to the same contact.

You design human checkpoints. You know which decisions need a human in the loop and which ones you can automate away. This isn't risk aversion — it's architecture.

You troubleshoot production systems. Agents fail in specific, weird ways. The skill of diagnosing an agent loop is different from debugging a Python script. You need pattern recognition across both.

You optimize cost-quality tradeoffs. Running Claude Opus on every task is expensive. Running Gemini Flash on everything misses quality gates. Routing the right model to the right task at the right frequency is a real operational skill.

You build and maintain the pipeline. Cron jobs, SQLite databases, approval queues, skill registries, message routing — someone has to own this layer.

The Differentiator Most People Are Missing

Here's the thing about the job market for AI operator roles: almost everyone claiming this skill has theoretical or adjacent experience. They've read the papers. They've run the demos. They've used Claude or ChatGPT to automate a few tasks.

Very few have built and operated a production system.

My current setup runs 42 scheduled jobs across scanning, research, conversion, and content workflows. It routes tasks across multiple models based on complexity and cost. It maintains a SQLite pipeline with ~4,000 opportunities, tracks approvals, and logs every action. It handles browser automation across sites with active bot detection. It sends Telegram messages for human approval on external-facing actions and runs autonomously on everything else.

That's not a portfolio piece I built to show off. It's infrastructure I depend on. The difference matters — infrastructure has to work. Demo code doesn't.

What the Job Market Is Doing

AI agent roles on Glassdoor hit 2,178 in March 2026. The non-engineering positions emerging are real:

AI Operations Manager — monitors deployed agents, handles escalations, optimizes performance. Strong ops background transfers directly.
Growth AI Operator — scales content and growth output using AI pipelines. If you've built this kind of system, you're already doing the job.
AI Community Manager — companies building AI agent platforms need people who understand both the technology and the communities being served.
AI Agent Strategist — scoping and shipping agent deployments. The early-stage version of this role at places like Sierra AI pays $140-280K.

The crypto + AI intersection is particularly active. Protocols need help running agent-driven community operations, airdrop automation, and growth pipelines. The people with both AI operations depth and crypto-native context are genuinely rare.

Why This Matters Now

The window where "I've actually built and run this stuff" is a meaningful differentiator is shorter than most people think. As frameworks mature and deployment patterns standardize, the bar will shift from "do you know how to do this at all" to "how well and how fast."

If you've been building in this space — actually building, not just theorizing — document it. Write about the weird failures. Explain what broke and why. Show the architecture.

That's the portfolio that matters for the roles that are opening up.

Nathaniel Hamlett is an operator and strategist with experience in AI agent systems, community operations, and crypto-native growth. He currently runs autonomous pipeline infrastructure handling research, outreach, and content workflows.

The AI Agent Ecosystem in 2026: What's Actually Working (and What's Getting Canceled)

Nathaniel Hamlett — Thu, 19 Mar 2026 00:37:21 +0000

The AI agent space has gone through a full hype cycle in about 18 months. We're now past the "will this work?" phase and deep into "how do we make this reliable?" — and the answer is more interesting than most people expected.

Here's what the landscape actually looks like in early 2026, based on what's shipping, what's failing, and what's emerging as real infrastructure.

The Framework Landscape Has Consolidated

A year ago, there were a dozen frameworks competing for mindshare. The stack has thinned out:

LangGraph (the stateful orchestration layer on top of LangChain) has won for complex, multi-step agent work. 47M+ PyPI downloads. It's the ecosystem anchor.

CrewAI is the fastest-growing option for multi-agent setups with role-based delegation — teams of agents with defined responsibilities.

AutoGen is effectively dead as a standalone project. Microsoft absorbed it into Semantic Kernel, rebranded as "Microsoft Agent Framework," targeting GA in Q1 2026.

OpenAI Agents SDK is gaining traction on low-friction alone. Easy to start, limited for complex work, but that's enough for a large swath of use cases.

The GitHub signal is telling: repos with 1K+ stars in the agent space grew 535% from 2024 to 2025 — from 14 to 89 repos. The tooling layer is exploding.

Two Protocols Are Becoming Plumbing

Two standards are racing to become foundational infrastructure:

MCP (Model Context Protocol, Anthropic) is winning the "how agents connect to tools" problem. It's a standardized way to expose tools and context to any agent, regardless of framework. Adoption is accelerating across the ecosystem.

A2A (Agent-to-Agent, Google) is a competing bet for peer-to-peer agent coordination without central orchestration. Still early, but Google's backing makes it a serious contender.

If these two succeed, agent development starts to look less like glue code and more like assembling standard interfaces.

The Architectural Patterns That Are Winning

After watching a lot of production deployments fail and a few succeed, some patterns are clearly working better than others:

Puppeteer + Specialists is the dominant mental model. One orchestrator breaks a task down, delegates to specialists (researcher, coder, validator, writer), and synthesizes the results. Clean separation of concerns. Easier to debug when something goes wrong.

Three-layer memory (working memory → cache → long-term store) has become a serious engineering problem. Shared vs. distributed memory across agents matters a lot for coherence. This is where a lot of production systems are currently struggling.

Typed interfaces over free-text is replacing LLM-to-LLM chattiness. Structured JSON outputs between agents reduce hallucination surface and make agent pipelines more predictable. Less elegant, more reliable.

ReAct, tool use, and reflection are still core patterns. Planning and multi-agent collaboration are maturing fast.

The Commercial Reality Is Messier Than the Press Releases

Gartner projects 40% of enterprise applications will include task-specific agents by end 2026 (up from under 5% in 2025). IBM and Salesforce estimate 1 billion agents in operation by end of year.

The counter-signal, also from Gartner: 40%+ of agentic AI projects will be canceled by 2027. Cost overruns, unclear ROI, data integration failures.

The gap between "deployed a demo" and "running reliable production workloads" is where most enterprise AI agent projects are currently living. The heaviest real deployments are happening in customer service, software development assist, content ops, logistics, and banking workflows — domains with clear, repeatable tasks and existing data infrastructure.

The Shift Nobody Is Writing About: The "Right Operator" Problem

Community sentiment in late 2025 through early 2026 has quietly shifted. The "replace humans" narrative has cooled. The dominant frame is now: force multiplier for the right operator.

This matters more than it might seem.

Running agents reliably isn't a pure developer problem. It requires someone who understands what agents can and can't do, can troubleshoot when they loop or hallucinate, knows how to design meaningful human-in-the-loop checkpoints, and can manage the reliability/cost tradeoffs at scale.

That's not a software engineering skill. It's an operational skill — closer to systems thinking, workflow design, and knowing when to trust automation vs. when to intervene.

The market for this skill is emerging and not yet crowded. Protocols and companies building agent-driven operations — community growth, automated outreach, content ops, pipeline management — increasingly need someone who can actually run these systems, not just architect them in theory.

The frameworks will commoditize. The operational layer won't.

Nathaniel Hamlett works at the intersection of AI operations, community, and growth for crypto protocols and frontier tech companies. Reach out if you're building something that needs an operator, not just an advisor.

I Tracked 3,570 Job Listings With an AI. Here's Which Job Boards Are Actually Worth Your Time.

Nathaniel Hamlett — Wed, 18 Mar 2026 00:32:44 +0000

Originally published at nathanhamlett.com

Most job search advice is anecdotal. "I got hired through LinkedIn!" or "HackerNews Who's Hiring changed my life!" are stories, not data. They reflect one outcome from a search nobody documented systematically.

I took a different approach. I built an autonomous AI agent to manage my job search. It scans sources, scores opportunities, builds application packets, and submits them. After a few months, I have something most job seekers don't: a database.

3,570 opportunities. 73 applications submitted. 16 source integrations. Enough signal to say what's worth your time and what isn't.

The Setup

My agent (which I've written about before) integrates a dozen job sources:

General aggregators: Jooble, Adzuna, Indeed, The Muse, Arbeitnow
Niche/specialized boards: CryptoCurrencyJobs, web3.career, HackerNews Who's Hiring
Telegram channels: @jobstash, @web3hiring, and a few others
Government: USAJobs
Applicant tracking system direct scrapes: Lever, Greenhouse, Ashby listings

Every opportunity gets scored 1-10 for fit. Anything above 7.0 moves forward to research and application.

"Applied rate" here means: of all listings from a given source, what percentage actually got an application submitted? It accounts for scoring, verification, ATS issues, and everything in between. It's the only metric that matters.

The Results

Here's the applied rate for every source with at least 20 listings in the database:

Source	Listings Scanned	Applications	Applied Rate
CryptoCurrencyJobs	55	11	20.0%
@jobstash (Telegram)	26	2	7.7%
@web3hiring (Telegram)	29	2	6.9%
HackerNews	176	7	4.0%
web3.career	129	5	3.9%
Adzuna	915	9	1.0%
USAJobs	103	1	1.0%
Jooble	1,342	9	0.7%
Indeed	38	0	0.0%
The Muse	36	0	0.0%
Arbeitnow	69	0	0.0%
Jooble (local)	169	0	0.0%

The spread is brutal. CryptoCurrencyJobs produces 28x better yield than Jooble. The Telegram channels punch above their weight relative to volume.

Jooble and Adzuna together account for 2,257 listings — more than 63% of total scan volume — and produced 18 applications between them. That's 0.8% efficiency after consuming the majority of resources.

Why Niche Boards Dominate

The pattern is consistent with something I suspected but couldn't prove before the data: aggregators waste your time. They scrape the same listings from everywhere, serve them at scale, and the signal-to-noise ratio collapses. Here's why niche boards win:

1. Better fit out of the gate. CryptoCurrencyJobs only lists crypto roles. Every listing is a potential fit. Jooble lists everything — the same search query surfaces cyber security analysts, chemical plant operators, and medical sales reps before it finds community managers.

2. Lower competition. Popular general boards are where every job seeker looks. Niche boards and Telegram channels attract more specialized applicants, but fewer of them. A 20% applied rate might mean the signal is strong and the competition is smaller.

3. Less staleness. General aggregators cache listings. I've applied to roles that were already closed before I found them, confirmed by 404 errors on submit. Niche boards and Telegram channels tend to be more real-time.

The Role Term Signal

The database also surfaced something useful: which words in job titles predict a good fit match.

I ran a simple lift calculation — comparing how often a term appears in titles where I actually applied vs. how often it appears overall. Higher lift = stronger signal.

Term	Lift
"founding"	10.87x
"contract"	9.17x
"ops"	8.63x
"media"	5.54x
"partnerships"	5.15x
"social"	4.58x
"growth"	4.12x

"Founding" at 10.87x means I'm disproportionately drawn to founding-team roles — early, high-agency, lower structure. "Contract" at 9.17x reflects that short-term engagements align better with my current situation than a long hiring process.

If you're building a job search system or even just thinking about how to filter manually, these terms are a starting point. Your lift numbers will be different, but the methodology applies.

What I'm Changing

Based on this data, I'm adjusting the scan strategy:

Reduce Jooble and Adzuna scan volume by 40% and redirect that capacity to better sources. They'll stay in the mix because occasionally they surface something unique, but they won't dominate.
Add more Telegram channels. The yield is strong and the volume is manageable.
Build a source-efficiency tracker that updates weekly so drift is visible before it becomes a problem.
Add blocker routing. 11% of actionable opportunities hit anti-bot walls (Cloudflare, hCaptcha) during submission. Instead of retrying blind, route those to a headed browser queue.

The Underlying Lesson

More input doesn't mean more output. Jooble has 1,342 listings in my database and produced the same number of applications as CryptoCurrencyJobs with 55.

For job seekers without an AI doing this at scale: the math translates. Spending three hours carefully working through HackerNews Who's Hiring and a couple of niche boards for your field will beat spending three hours on Indeed. The surface area looks smaller but the yield is higher and the applications are better.

Data doesn't lie. Job boards do.

I write about operating AI agents, non-traditional career paths, and building systems that work while you sleep. I'm currently available for consulting engagements, contract work, and full-time roles in AI operations, community, and growth. Reach me at nathanhamlett.com.

Production AI Agents Don't Work Like You Think: Architecture Patterns That Actually Scale

Nathaniel Hamlett — Tue, 17 Mar 2026 19:22:01 +0000

There's a gap between how AI agents are demoed and how they're actually deployed at scale.

The demo version: one big model with 30 tools attached, given a goal, and told to "figure it out." Impressive for 90 seconds. Unreliable in production.

The production version looks almost nothing like that. And understanding the difference matters—not just for engineers, but for anyone trying to deploy autonomous AI systems that keep working instead of degrading after a week.

Why Monolithic Agents Fail in Production

The appeal of a single, powerful model with access to everything is obvious. But in practice, monolithic agents hit predictable walls:

Context window saturation. When you give a model 30+ tools, the context required to reason about which tool to use and maintain task state and track history starts consuming your available window. By the time you're on step 8 of a 12-step task, performance has already degraded.

Tool selection drift. Studies on production agent deployments show accuracy drops sharply after ~15 available tools. The model starts making worse choices—not because the model is bad, but because the selection problem becomes harder than the actual task.

No control surfaces. If something goes wrong in a monolithic agent mid-run, you have limited options: let it finish, kill it, or hope the retry logic handles it. There's no clean place to interrupt, review, or redirect.

Two Patterns That Actually Work

By 2026, production AI systems have largely converged on two architectures:

1. Multi-Agent Graphs (Agentic Workflows)

Frameworks like LangGraph and AutoGen implement this pattern: a directed graph where each node is a specialized agent (often a smaller, cheaper model) with a narrow task. The graph defines the flow explicitly.

The strengths: predictability, parallelism, auditability. You can run multiple branches simultaneously. You can inspect the state at any edge. Failures are localized.

The weaknesses: rigidity. Graph-based systems require you to specify the decision tree in advance. Novel situations fall off the edges. They're excellent for enterprise workflows where the process is known and stable—less useful for exploratory or adaptive tasks.

2. LLM Skills (Modular Extensions)

The other dominant pattern: a core generalist model augmented with dynamically loaded "skills"—structured knowledge and code templates that load contextually based on task type.

Instead of a model choosing from 30 tools, it operates with a small core toolset and loads a skill only when that skill is relevant. The skill provides domain context, templates, constraints, and specific tool patterns—without permanently bloating the base context.

This is the architecture I've been running in my own pipeline: a core model (Claude Sonnet/Opus for conversation and orchestration, Gemini for bulk research) with 34+ targeted skills that load based on pipeline state and trigger keywords.

The cron and heartbeat system acts as a lightweight orchestrator—triggering specific skills based on database state rather than relying on the LLM to constantly re-plan its day. That "constant re-planning" burns tokens, introduces latency, and creates unpredictable execution paths.

The Memory Layer Is Where Most Agents Fall Apart

Every production agent architecture has to answer the same question: what does the agent remember, and how does it retrieve it?

Most tutorials skip this entirely. Most demos use in-context "memory" (just stuffing prior messages back in). That works for demos. It doesn't work when your agent has been running for six months.

A functional memory architecture needs at least three layers:

Short-term: Session state and recent actions. For most systems, this is a combination of in-context history and a lightweight log file.

Episodic/Structured: A queryable record of what happened. SQL is underrated here—a SQLite pipeline database with timestamped events, stage transitions, and outcome tracking gives you something you can actually query and reason over. Vector databases are powerful for semantic retrieval but add operational complexity.

Long-term/Semantic: The hardest layer. How does the agent know what it knows without stuffing everything in context? The most practical current approach is structured markdown (curated knowledge files) combined with keyword-triggered loading. Semantic caching and local embedding search (sqlite-vss or Chroma) are the next step for systems that need it.

The failure mode to avoid: treating memory as a flat append-only log that grows until it breaks things. Memory needs a decay function, a curation process, and selective retrieval—not just accumulation.

Human-in-the-Loop Isn't a Safety Net—It's a Design Pattern

The enterprise world is currently struggling to implement meaningful human oversight of AI agents. Most "HITL" implementations are either too aggressive (interrupt on everything, agents become useless) or too passive (approve in bulk, oversight is theater).

The pattern that works: classify actions before execution, not after.

Every action the agent can take gets assigned to a class: autonomous (execute immediately), approval-required (draft and queue for human review), or hard-banned (never attempt). The model knows this classification and structures its behavior around it.

In my system, this looks like:

Class 1: Research, analysis, file writes, internal scans. Execute immediately.
Class 2: Anything external-facing—sending messages, submitting applications, publishing content. Draft thoroughly, send to Telegram for approval, wait for explicit confirm.
Class 3: Legal commitments, financial transactions, identity-sensitive actions. Hard-banned.

The result: the agent moves fast on internal work while maintaining a clean audit trail of every external action, with human decision points exactly where they matter.

The Observability Problem Nobody Talks About

Production agents fail silently. A scan returns zero results. A submission gets a 428. An API key expires. Most systems either surface nothing or surface everything—neither is useful.

What actually works: structured logging with categorized failure modes, a human-readable daily summary, and push notifications for things that need attention. The agent should know the difference between a transient failure (retry in 30 minutes) and a structural failure (needs a code change) and surface them differently.

Telegram briefings for attention-required items, daily notes for full context, and a SQLite audit table for everything else has worked well in practice.

What This Means If You're Building

The lessons from running a production agent system for several months:

Narrow the toolset. A model with 8 highly relevant tools outperforms one with 30 generic tools.
Make state explicit. Relying on the model to maintain implicit state across long sessions is fragile. Write it to a database or a file.
Classify before execute. Build your action classification system first. Everything else plugs into it.
Plan for memory debt. Your context-stuffing approach works until it doesn't. Design the memory layer early.
Instrument everything. You can't improve what you can't measure. Log outcomes, not just actions.

The gap between "impressive demo" and "still running in 3 months" is almost entirely architectural. The intelligence of the underlying model matters less than most people think. The scaffolding around it matters a lot.

The Operational Chaos Behind $9B Prediction Markets

Nathaniel Hamlett — Sun, 15 Mar 2026 00:34:11 +0000

The Operational Chaos Behind $9B Prediction Markets: Why Playbooks Matter More Than Predictions

Prediction markets like Polymarket have recently seen explosive growth. With a $9B valuation, $2.3B in funding from heavyweights like ICE, Paradigm, and Founders Growth, and regulatory greenlights marking their return to the US market, the platform's external success is undeniable. But as someone who builds operational systems, I look past the staggering trading volume and into the internal machinery.

When a crypto company scales to 150+ employees and handles billions in volume across highly sensitive, real-world events, the product itself is rarely the primary bottleneck. The real danger is the fracture of internal operations.

The Hidden Bottleneck

In the early days of any high-growth startup, speed is everything. A small, tightly-knit team can rely on tribal knowledge—conversations in Slack, quick huddles, and undocumented processes—to keep the engine running. But as headcount crosses 50, then 100, and funding reaches the billions, that tribal knowledge becomes a liability.

When the next massive global event hits—whether it's an election, a macroeconomic shift, or a sudden crisis—the team cannot afford to ask, "How do we handle this?" The answers must already be documented. If they aren't, the result is operational debt, which manifests as delayed responses, internal friction, and ultimately, a degraded user experience.

The Symptoms of Operational Debt

Operational debt in a hyper-growth environment is easy to spot if you know what to look for:

Onboarding Friction: New hires take weeks to become productive because they have to hunt down basic information.
Siloed Information: Marketing doesn't know what Engineering is shipping, and Customer Support is caught completely off guard.
Reactive Firefighting: Instead of proactively building systems for the future, leadership spends all their time putting out daily fires.

For a platform dealing with complex and controversial markets—some of which have already drawn congressional scrutiny—relying on reactive firefighting is not just inefficient; it's existentially dangerous.

Building the Backbone

This is why roles like "Ops Associate" or "Operations Manager" are often the most critical hires in a scaling web3 company, despite lacking the flashiness of a smart contract engineer.

These are the builders of the operational backbone. They are the ones constructing advanced Notion workspaces, establishing cross-functional playbooks, and creating the reporting structures that allow the rest of the company to move at lightspeed without tearing itself apart. They translate the chaotic energy of a startup into repeatable, scalable processes.

A well-documented playbook isn't "boring corporate stuff"—it is the very foundation of scale. It ensures that when a controversy erupts or a market spikes unexpectedly, there is a clear, step-by-step protocol for how to handle it, who needs to be involved, and what the communication strategy will be.

Conclusion

Predicting the future is hard. Polymarket's users know this better than anyone. But predicting internal chaos is remarkably easy if you don't build operational playbooks early.

Scaling a platform without parallel scaling of internal processes isn't scaling a business—it's just scaling chaos. As the prediction market space continues to mature and face increased scrutiny, the winners won't just be the platforms with the best odds or the slickest UI. They will be the ones whose internal operations are as robust and reliable as the markets they offer.

If you're building in the web3 space, don't wait until the chaos is unmanageable. Build the backbone now. Because while the market might be unpredictable, your internal operations shouldn't be.