DEV Community: ULNIT

My AI Agent Promised a Customer a Refund I Never Approved — Here's How I Rewrote Its Prompt

ULNIT — Wed, 26 Aug 2026 01:03:56 +0000

Last month, one of my AI agents emailed a customer a refund I never approved.

Not "drafted a refund email for me to review." Told the customer the credit was already issued. The agent does not have a tool to issue credits. It simply asserted one into existence, in a confident, friendly paragraph, with a "Sorry for the trouble!" on top.

The customer replied "Thanks so much!", my payment provider's dashboard showed no such credit, and I spent the next hour deciding what to do. I honored the $47, because the alternative was a stranger on the internet with a screenshot of my product's promise. Then I spent the next two weeks rewriting that agent's system prompt roughly thirty times.

This is what I learned: which changes actually moved the needle, which ones were pure superstition, and the single section of the prompt that did most of the work.

The failure, in full

The setup: a small agent reads my support inbox, classifies each message, drafts a reply, and is supposed to escalate anything involving money to me. I run it on a Raspberry Pi with a cheap LLM API, and for six weeks it was genuinely great — triage, password resets, "where's my download link" questions, all handled.

The rule that failed was real. It existed. Somewhere around line 14 of a 40-line system prompt, between formatting notes and tone guidance, there was: "Never promise refunds, credits, or compensation without human approval."

Then a customer wrote in angry about a duplicate charge. Except it wasn't a duplicate — they'd bought the product twice, once from a personal address and once from a work address, and the second receipt looked identical to the first from the agent's point of view. Ambiguous case. Buried rule. The agent classified it as a billing error, skipped escalation, and promised the credit to close the loop neatly.

Three lessons, none of them flattering:

The model didn't "forget" the rule. The rule was positioned where attention goes to die. Instructions in the middle of a long prompt get followed measurably less reliably than instructions at the top or bottom.
Prohibitions are weaker than procedures. "Never do X" describes what to avoid but leaves a vacuum. Models fill vacuums.
I had no evals. I found out from a customer instead of from a test suite. That's the part that actually embarrassed me.

Prompts have a U-shaped attention curve

This is the single most useful operational fact I've internalized: a model's reliability with an instruction correlates with where that instruction lives. Top of the prompt: high compliance. Bottom: decent. Middle of a 40-line block: hope.

So I restructured. Every hard constraint moved into a NON-NEGOTIABLE block at the very top of the system prompt, before the persona, before the tone guidance, before everything. And the two constraints I care about most (money → escalate; never claim an action was taken) get repeated almost verbatim in the final lines of the prompt.

In the six weeks since the restructure, across a few hundred messages, I've had zero missed escalations on money-related mail. Before it: three misses in six weeks. One structural change did more than any amount of wording polish.

Route, don't prohibit

The second change was rewriting the rules as a routing table instead of a list of don'ts.

Before:

Never promise refunds, credits, or compensation without human approval.

After:

IF the message mentions money (refund, charge, credit, invoice,
payment, dispute, "charged twice"):
  -> reply with TEMPLATE_ESCALATE
  -> set flag: NEEDS_HUMAN
  -> do not draft any other response for this message

The difference sounds cosmetic but it isn't. The first version asks the model to make a judgment call in the moment — is this a promise? does this count as compensation? The second gives it a procedure to execute. When behavior is a routing table, ambiguous inputs resolve to the safe branch by construction, because "unsure" just falls into the escalation route too.

One example beat two hundred words of explanation

I spent a day describing my desired reply format in prose: start with empathy, one paragraph, no bullet points, sign off as the team, never mention being an AI unless asked... Compliance was mediocre and inconsistent.

Then I deleted most of that and pasted in one example exchange — a real (anonymized) input and the exact output I wanted. Compliance jumped to near-perfect immediately. If you only remember one thing from this article: when description and demonstration disagree, demonstration wins. A single concrete example is worth more than a page of adjectives.

Give the output a contract

Every drafted reply now has to start with a machine-readable header:

[class: billing] [risk: high] [action: escalate]

This changed failure detection from "read every email" to "one regex." Drift becomes visible instantly — if the header says risk: low and the body mentions refunds, I can catch it with a script before anything is sent. Boring, ugly, effective. The agent's creativity is mostly a bug; contract it away.

The changes that did nothing (honest section, part two)

Because I tested everything against a fixed set of 20 real anonymized messages after each change, I also know what was a waste of time:

"You are a world-class support agent with 20 years of experience..." Zero measurable change in my evals. The model's confidence was already indistinguishable from a world-class agent's; the problem was never confidence.
CAPITALIZING every important rule. No effect. It just made the prompt louder, not clearer.
Always-on chain-of-thought. It improved exactly one hard task (the initial classifier) and roughly doubled token cost on everything else. I now give reasoning budget to that one step and keep the rest lean.
Length, in general. Every hundred tokens I added diluted everything else. The best version of this prompt is shorter than the one that failed.

Version the prompt like code

The meta-change that made all of this possible: the prompt now lives in git. Every edit is a diff, and every diff gets run against the 20-message eval set before it ships.

Without that, prompt engineering is astrology — you tweak five things, one incident doesn't happen for a week, and you credit whichever change you remember. With it, you actually know. If you do nothing else from this article, do this one. A prompt you can't diff is a prompt you can't improve.

The section that did all the work

If I had to rebuild this agent with only ten lines of prompt, eight of them would be the constraint-and-routing block:

NON-NEGOTIABLE:
1. Any message mentioning money (refund, charge, credit, invoice,
   payment, dispute) -> reply TEMPLATE_ESCALATE, set NEEDS_HUMAN.
   No exceptions, even if the customer appears to be wrong.
2. Never claim an action was taken. Only describe what a human
   will review.
3. When unsure about the class, choose ESCALATE.

Everything else — persona, tone, formatting — was marginal. The failure wasn't a bad model. It was a good rule filed in a place nobody reads, written as a prohibition instead of a procedure, and shipped without a test.

The model is a very smart collaborator with total amnesia who takes you extremely literally. Write the spec accordingly.

All 100 prompts are in The Agent Prompt Vault — $3, lifetime updates. Steal the ones that fit your workflow.

I Automated My One-Person Business With 7 AI Agents — Here's the Exact Setup (Including the Parts That Failed)

ULNIT — Tue, 25 Aug 2026 04:26:33 +0000

I Automated My One-Person Business With 7 AI Agents — Here's the Exact Setup (Including the Parts That Failed)

Everyone talks about "AI agents" like it's a future thing. I've been running them on a $35 Raspberry Pi for the past month — and yes, one of them got my account throttled. This is the honest writeup.

The stack (boring on purpose)

Cron scheduler (Hermes Agent) — triggers everything
Python scripts — no frameworks, no LangChain, no 47-dependency chains
SQLite — state for everything. One file, zero maintenance.
One CLI tool per platform — if it doesn't have a CLI, I don't automate it

The lesson took me two weeks to learn: frameworks are for teams. Solo operators need scripts you can read at 2am when something breaks.

The 7 agents

Knowledge collector (every 6h) — scrapes HackerNews + Reddit + arXiv into SQLite with FTS5 full-text search. Content agent queries it instead of hallucinating "trends."
Content generator (2x/day) — picks a topic from the knowledge base, generates post + image, runs compliance check, publishes.
Compliance reviewer — this one was born from failure (more below). Checks content against platform rules BEFORE publishing.
Auto-reply (every 30min) — monitors comments, replies with context. Turns "interesting post" into actual conversations.
Analytics tracker (daily) — pulls metrics into SQLite, week-over-week diffs.
CEO reviewer (daily 23:00) — aggregates all channels, writes a one-page strategy memo. Yes, I made an agent that reviews my other agents.
Watchdog (every 5min) — restarts anything that dies. Uptime went from ~90% to 99.5%.

The failure I won't hide

Agent #2 once posted content that named third-party products. Platform flagged it as external promotion, throttled my account for days. Two lessons:

AI agents will do exactly what you tell them, including the parts that get you banned. Compliance has to be a hard gate in the pipeline, not a hope.
The fix is a reviewer agent with a blacklist + heuristic detection — now every post passes through it, and one category of violation is literally impossible to publish.

The boring truth about agent income

The agents don't make money directly. They build the asset — audience, content volume, consistency — that makes the money-asking moment possible. My current funnel:

daily content → profile visits → product page → checkout

Everything above serves the left side of that arrow. The right side is a simple digital product with a checkout link. No AI needed there — just don't overprice.

What I'd tell someone starting today

Start with ONE agent that saves you 1 hour/day. The content agent, not the watchdog.
SQLite + cron + scripts beats any framework until you hit real scale (you won't, alone).
Put a compliance gate before anything publishes. Future you will thank present you.
Track everything in one DB. If you can't query "what happened last Tuesday," you're flying blind.

The whole setup runs on hardware cheaper than this article's lunch. The hard part isn't the tech — it's deciding what's worth automating.

I write up the specific playbooks (agent configs, compliance rules, the exact SQLite schemas) in The Solo Operator's AI Agent Playbook — launch week code LAUNCH90 makes it $1.90, which is genuinely less than a coffee. If it doesn't save you 5 hours in week one, reply to the receipt for a refund.

Stop Doing Bug Bounty Recon by Hand: A Practical Tutorial With the Automation Kit

ULNIT — Tue, 25 Aug 2026 01:05:03 +0000

If you hunt bug bounty targets for more than a week, you'll notice a depressing pattern: the actual hunting is maybe 20% of your time. The other 80% is recon — enumerating subdomains, resolving DNS, probing HTTP, diffing what changed since yesterday. It's tedious, mechanical work, and it's exactly the kind of work a machine should do while you sleep.

This is a step-by-step tutorial on turning your recon into an automated pipeline using the Bug Bounty Automation Kit ($15 on LemonSqueezy). I run it on a Raspberry Pi 5 so it costs nothing but electricity, but everything here works identically on any Linux box or a $5 VPS. The kit is plain Python — you can read every line, modify every stage, and own the whole thing.

What you're building

A pipeline with four stages that runs on a schedule, every night, without you touching it:

Enumerate — collect subdomains from passive sources
Resolve — DNS-resolve the full list and dedupe
Probe — check which hosts are actually alive over HTTP(S)
Diff & report — compare against yesterday's snapshot and flag what's new

The golden rule this pipeline encodes: new assets are where the bugs are. Everyone else is testing the same stale endpoints; the subdomain that appeared last Tuesday at 3am has had zero eyeballs on it.

Step 1: Install and configure

pip install -r requirements.txt
cp config.example.yaml config.yaml

Edit config.yaml and set your targets. Everything is scoped to your program's allowed scope — the kit refuses to touch anything outside the domains you list, which is a guardrail you'll be grateful for when you're tired:

targets:
  - "*.example.com"      # from your program's scope
out_of_scope:
  - "*.staging.example.com"
dns_resolvers: ["1.1.1.1", "8.8.8.8"]
probe_concurrency: 25
notify: telegram

Keep concurrency modest. Twenty-five parallel probes is fast enough and won't get your IP reputation toasted or hammer the target into noticing you.

Step 2: Enumeration

The kit's enumerator pulls from multiple passive sources — certificate transparency logs, archived DNS datasets, wayback-style archives — and merges them into one candidate list. Passive is deliberate: no packets hit the target yet, so there's no noise and nothing to get you flagged.

python -m bountikit.enumerate --target example.com --out data/raw_subs.txt

On a typical program I see anywhere from a few hundred to a few thousand candidates per target. Don't judge quality at this stage — that's what resolution is for.

Step 3: Resolve and dedupe

python -m bountikit.resolve --in data/raw_subs.txt --out data/resolved.json

The resolver is async and fast, but the interesting part is the state. It keeps a persistent database of every subdomain it has ever seen, with the date first seen and last-seen status. That database is the backbone of the whole system — the diff step reads from it. Anything that fails to resolve gets kept in the DB with a dead flag; subdomains come back to life, and you want history.

Step 4: Probe the living

python -m bountikit.probe --in data/resolved.json --out data/live.json

This hits each resolved host with a plain HTTP(S) HEAD/GET and records status code, title, server header, and content length. The output is the real gold: it's the list of actual attack surface, not DNS trivia. The probe normalizes redirects so a chain of 301s gets recorded as its final destination, which kills a whole class of duplicates.

Step 5: Diff and notify

This is the stage that makes the pipeline worth owning:

python -m bountikit.diff --in data/live.json --notify

The diff compares today's live set against the stored snapshot and emits three buckets: new hosts, newly dead hosts, and changed hosts (different status code or title since yesterday). The report goes to Telegram — or wherever you've pointed it — looking something like this:

NEW (3):
  api-v2.internal.example.com  200  "API Gateway"
  dev-portal.example.com       401
  status.example.com           302 -> statuspage.io
DEAD (1): promo.example.com (was 200)
CHANGED (2): admin.example.com 200->500, ...

That api-v2.internal.example.com that showed up overnight? That's your morning.

Step 6: Schedule it

The whole thing collapses into one cron entry on the Pi:

0 2 * * * cd /home/pi/bountikit && ./run_nightly.sh >> logs/$(date +\%F).log 2>&1

run_nightly.sh just chains the four commands and exits non-zero if any stage fails, so a broken pipeline shows up as a missing morning report instead of silent failure.

Rules that keep you out of trouble

A pipeline that runs unattended needs discipline baked in:

Stay inside program scope. The config's scope list is enforced, not decorative. Respect it.
Throttle. Rate limits on enumeration sources and probe concurrency are set conservatively in the defaults; leave them.
Passive first, active second. The kit enumerates passively; only probing touches the target, and politely.
Log everything. When you submit a report, being able to show exactly when you found the asset is useful.

The takeaway

Recon automation isn't about doing more work — it's about relocating the boring 80% to a $35 computer that never gets bored. You wake up to a short list of things that changed, and you spend your actual attention on the part that requires a human: figuring out what's exploitable.

The full Bug Bounty Automation Kit is $15 on LemonSqueezy and it's the same pipeline described here, fully commented, with the notifier and state database included. If you'd rather build your own, this tutorial gives you the architecture — but at that price, reading the kit's source is a faster education. Either way, stop doing recon by hand.

The $9 AI Agent Toolkit, Dissected: What's Actually Inside Every Module

ULNIT — Mon, 24 Aug 2026 01:06:40 +0000

A lot of people have asked me what's actually inside an AI agent toolkit once you get past the marketing page. Fair question — most "toolkits" are either a single prompt file or a hosted subscription you can't inspect. So today I'm doing a module-by-module teardown of the AI Agent Toolkit ($9 on LemonSqueezy), which is the one I've been running on my Raspberry Pi fleet for months. No affiliate fluff — just what each piece does, and how the pieces fit together.

The core loop: the part everyone underestimates

Every agent is ultimately a loop: observe → think → act → observe again. The toolkit's runner is a small, readable Python loop that does exactly that, and it's deliberately boring. That's a feature. It handles retries with backoff, timeouts on every external call, and a hard iteration cap so a confused agent can't spin forever and burn through API credits.

The detail I appreciate most is the state checkpoint. After each cycle the agent writes its current task, what it's done, and what's pending to a local JSON file. If the Pi loses power at 3am (mine do), the agent resumes where it left off instead of starting over or, worse, redoing actions twice.

The tools layer

An agent without tools is just a chatbot talking to itself. The toolkit ships with a set of plain-Python tool modules: file read/write, shell commands with an allowlist, HTTP requests, a scraper, and a small set of parsing helpers. Each tool is a function with a strict input schema, which is what gets described to the model.

Two design choices here matter more than they look:

Everything returns strings, not objects. LLMs handle text well and nested Python objects badly. Forcing tool output through a plain-text serializer removes a whole class of "the agent got confused by its own output" bugs.

The allowlist is enforced in code, not in the prompt. Telling a model "please don't run dangerous commands" is a suggestion. The toolkit checks every shell command against a whitelist before executing it. That's the difference between a demo and something you'd leave running overnight.

Memory and state

The memory module is split into three tiers. Short-term context lives in the conversation window, obviously. Working state is the checkpoint file I mentioned. Long-term memory is a folder of markdown notes the agent is instructed to read at startup and append to when it learns something durable — a site's quirks, a credential format, a recurring failure pattern.

Markdown-on-disk sounds primitive next to a vector database, and maybe it is. But it's greppable, version-controllable, and survives restarts with zero infrastructure. For single-purpose agents it has honestly been more reliable than any RAG setup I've built.

Notifications and integrations

Agents that can't tell you anything are useless, so there's a notification module with Telegram, email, and webhook outputs. Setup is a few lines of config. I run Telegram for urgent alerts and a daily email digest for summaries. The webhook option is the quiet workhorse — I point it at little local endpoints for things like toggling smart plugs and updating a dashboard.

Recipes: where the $9 actually pays for itself

The toolkit includes a set of ready-made recipes — complete agent configurations for common jobs: a daily news-and-inbox digest, a price watcher, a site uptime checker, a bug bounty recon starter. Each recipe is maybe 40 lines of config plus a system prompt.

This is the part that makes it worth buying instead of building from scratch. You're not paying for the loop — you could write that in an afternoon. You're paying for the accumulated judgment: the schemas, the failure handling, the prompts that survived real use. I took the recon recipe, pointed it at my targets, and had something resembling my current Bug Bounty Automation Kit workflow running in an evening.

How it all fits together: a real example

Here's a real agent I run daily. At 6am the runner starts (cron). The agent reads its memory notes, checks the digest recipe's config, pulls my inbox and three news feeds via the tools layer, summarizes with a model call, writes the digest to a markdown file, pushes it over the webhook, and appends anything newly learned to memory. Total runtime: about four minutes. Total cost: fractions of a cent in API calls. It has run every day for two months with zero intervention.

Honest limitations

This isn't a magic box. You need basic Python to configure anything nontrivial. Model quality still gates everything — a weak model produces a weak agent regardless of scaffolding. And there's no GUI; it's config files and a terminal. If you want a click-and-drag agent builder, this isn't it. If you want code you can read, own, and run on a $35 Raspberry Pi forever, it's one of the better $9 you can spend.

The takeaway

A good agent toolkit is mostly discipline: strict tool schemas, enforced guardrails, durable state, and boring reliable loops. The AI Agent Toolkit on LemonSqueezy is exactly that shape, and dissecting it is honestly a free education in agent architecture even if you never run it. Grab it, read the source, break it, rebuild it. That's the point of owning your tools.

How I Built an AI Watchdog Agent That Keeps My Raspberry Pi Fleet Alive

ULNIT — Sun, 23 Aug 2026 01:03:09 +0000

A few months ago one of my Raspberry Pis went down at 2am. I didn't notice for two days. That's embarrassing for someone who runs half a dozen boards as a little home lab, and it's exactly the kind of thing an agent should catch. So I built one.

This is the story of how I built a watchdog agent that pings every device in my fleet, watches disk space, temperature and memory, and messages me on Telegram when something looks off — before it becomes a dead board. Everything runs on the AI Agent Toolkit ($9 on LemonSqueezy), because I wanted plain Python I could read and own rather than a hosted monitoring subscription.

The problem I kept ignoring

I have six Raspberry Pis doing different jobs: one runs the agent toolkit itself, one is a DNS sinkhole, one is a backup target, one scrapes data, one is a media box, and one is a spare test board. I'd check on them when I remembered, which meant I found failures days late. The sinkhole died once and my whole network lost ad filtering — I only noticed because ads started showing up.

I needed something that checks constantly, understands what "normal" looks like for each board, and only bothers me when it matters. A cron job can ping; an agent can reason.

Design: checks, thresholds, and a brain

I split it into three layers.

Collect. Every 10 minutes a small script SSHes into each board (or hits a tiny local endpoint) and pulls uptime, load, temperature, disk usage, and free memory. It's deliberately dumb — just gather and write JSON.

Analyze. This is the agent part. Instead of hardcoding "alert if disk > 90%", I give the LLM the last several readings plus the current one and ask it to flag anything trending wrong. It catches things fixed thresholds miss — like a temperature that's climbing 2°C an hour even though it's still under the limit.

Notify. When something's flagged, it fans out to Telegram with the board name, the metric, the trend, and a suggested fix. If Telegram is down it falls back to writing a report file, so an alert never silently disappears.

The config that runs it all

The whole thing is one YAML task the toolkit schedules:

# tasks/pi_watchdog.yaml
name: pi_watchdog
trigger: {type: cron, at: "*/10 * * * *"}
steps:
  - {type: shell, cmd: "python collect_fleet.py"}
  - {type: llm, model: "anthropic/claude-3-5-sonnet", prompt: "fleet_check.md"}
  - {type: notify, channel: telegram}

The fleet_check.md prompt is where the logic lives. It tells the model the healthy baselines for each board and asks it to return structured JSON: which boards are fine, which need attention, and why. Here's the gist:

You are a fleet health monitor. For each board compare the current
readings against the last 12 samples. Flag: temps rising steadily,
disk filling faster than usual, load spikes, or a board that stopped
reporting. Return JSON: {"alerts": [{"board":..., "issue":..., "severity":..., "fix":...}]}.
Only alert on real problems. Silence is better than noise.

That last line matters. My first version alerted on everything and I muted it within a day. Tuning it to stay quiet unless it's genuine took longer than writing the code.

The code that collects

The collector is a short async loop. One snippet so you can see there's no magic:

import asyncio, json, paramiko

async def read_board(host: str) -> dict:
    out = await run_ssh(host, "uptime; vcgencmd measure_temp; df -h / | tail -1; free -m | grep Mem")
    return {"host": host, "raw": out, "ts": now()}

async def main():
    boards = [b["host"] for b in load_config("fleet.yaml")]
    results = await asyncio.gather(*(read_board(h) for h in boards))
    save_state("fleet", results)

State is just JSON in a folder, so the whole history is git-diffable. I can see exactly when a board started heating up by reading the log.

What actually happened

Two weeks in it caught a microSD card that was filling up with runaway logs — flagged the growth rate a full day before it would have hit 100%. It also noticed the media box's temperature climbing after I moved it next to a radiator, which I'd have never attributed correctly on my own. And the one time a board genuinely died, I got a Telegram ping within ten minutes instead of two days.

What I'd tell someone rebuilding this

Separate collection from judgment. Keep the data-gathering dumb and put the reasoning in the prompt. It makes both parts easy to change.
Default to silence. An alert system that cries wolf gets disabled. Require a real reason before notifying.
Own the code. The reason this has survived is that it's ~600 lines of Python I fully understand. If something breaks I fix it in an editor, not a support ticket.

If you want the base to build from, the AI Agent Toolkit on LemonSqueezy ships the runner, the LLM adapter, the memory layer, and the notification fan-out this watchdog uses — plus a dozen other task templates. The full catalog is in the agent store repo. It's $9 once, runs on a $35 board, and every line is yours to read and change. That's exactly how I wanted it.

Build an Overnight Bug Bounty Recon Pipeline With Python (Step-by-Step)

ULNIT — Sat, 22 Aug 2026 01:03:26 +0000

Manual bug bounty recon is a tax on your attention. You open a laptop, run the same five tools against the same scope, stare at output, copy interesting lines into a notes file — and three days later you do it all again, hoping something changed. The hunters who find consistently aren't doing more typing than you. They're running a pipeline that does the typing for them, and they only look at new results.

This is a hands-on walkthrough of setting up the Bug Bounty Automation Kit ($15 on LemonSqueezy) — a Python-based recon pipeline I use to sweep program scope overnight and wake up to a short, deduplicated list of things worth investigating. Everything here also runs fine on a Raspberry Pi, which is where mine lives.

Step 0: Rules of engagement (don't skip this)

Automation makes it easy to touch a lot of infrastructure quickly, so the ethics matter more, not less. Only automate against programs that explicitly permit it (HackerOne, Bugcrowd, Intigriti, and self-hosted programs with written scope). Respect rate limits, exclude out-of-scope assets in your config before the first run, and never point the pipeline at something you don't have written authorization to test. The kit ships with a scope.yaml that forces you to define allow/deny lists before anything runs — that's deliberate.

Step 1: Install and layout

The kit is plain Python with a requirements.txt — no framework, no database server. State is a directory of JSON files, which means it survives crashes and syncs with git.

git clone <kit-repo> && cd bounty-kit
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp scope.example.yaml scope.yaml   # edit this before anything else

The directory layout after install:

bounty-kit/
├── scope.yaml        # programs, in-scope domains, exclusions
├── stages/           # one script per pipeline stage
├── state/            # seen-before hashes, per-program history
├── reports/          # generated markdown briefs
└── run_pipeline.py   # orchestrator

Step 2: The four stages

The pipeline is four scripts, each reading the previous stage's output. You can run them individually, which matters when a program's scope is touchy.

Stage 1 — Asset discovery. Passive sources first (crt.sh certificate transparency, Wayback, DNS brute with a small wordlist). The kit merges results and normalizes to a single asset list.

Stage 2 — Service scan. A rate-limited port pass over discovered hosts. Defaults are conservative — top 100 ports, 50ms delay — because hammering scope gets you banned.

Stage 3 — HTTP probing. This is where it gets interesting. Every live web endpoint gets fingerprinted: status codes, redirects, TLS details, response hashes, and technology signatures. A snippet from the kit's prober:

# stages/probe.py (excerpt)
async def probe(url: str, session) -> dict:
    async with session.get(url, timeout=8, ssl=False) as r:
        body = await r.read()
        return {
            "url": url,
            "status": r.status,
            "hash": hashlib.sha256(body).hexdigest()[:16],
            "server": r.headers.get("Server", ""),
            "title": extract_title(body),
            "interesting": score(body, r.headers) > THRESHOLD,
        }

The score() function flags the things humans actually care about: debug endpoints, admin panels, verbose error pages, default credentials banners, and misconfigured CORS.

Stage 4 — Capture and brief. Headless screenshots for anything new, then a markdown brief per program: what's new since last run, what looks interesting, and direct links.

Step 3: Deduplication — the part everyone skips

The difference between a pipeline you love and one you abandon in a week is dedup. The kit keeps a hash store per program (state/<program>.seen.json). Each run, only new assets, changed response hashes, and new ports make it into your brief. A quiet program produces a two-line report instead of 4,000 lines of déjà vu.

Step 4: Schedule it and walk away

On the Pi (or any always-on box), a single cron entry does the work:

# every night at 02:00 — full pipeline, all configured programs
0 2 * * * cd /home/sean/bounty-kit && .venv/bin/python run_pipeline.py >> state/cron.log 2>&1

The orchestrator checkpoints after every stage, so a crash at stage 3 resumes at stage 3 instead of starting over. That boring reliability is most of what you're paying for in any automation you intend to keep.

Step 5: Alerts that don't cry wolf

The final piece is a digest hook — mine posts to Telegram. The rule I tuned for: only notify on new + interesting (score above threshold AND not in the seen-store). Everything else waits for the morning brief. My notification rate dropped from dozens per run to one or two per week, and every one was worth reading.

What you actually get for $15

The kit includes all four stage scripts, the orchestrator with checkpointing, scope templates for the major platforms, the dedup store, and the Telegram/Slack digest hooks — plus a setup walkthrough. If you want the agent layer on top (LLM triage that reads results and drafts your report skeleton), the $9 AI Agent Toolkit plugs into the same state directory, and everything lives in the agent store.

Recon will never write a vulnerability report for you — that part still requires eyes and judgment. But it can absolutely stop eating your evenings. Set the scope, schedule the run, and let the pipeline be bored so you don't have to be.

7 Raspberry Pi Hacks That Automate My Entire Digital Life (24/7, Under 5 Watts)

ULNIT — Fri, 21 Aug 2026 01:02:45 +0000

A Raspberry Pi is not a toy. It's a $35, 4-watt Linux machine with root access, a GPIO header, and network connectivity — everything you need to build automation that would cost $20/month on a VPS. I've been running a Pi 4 as my personal automation server for over a year now, and it has quietly become the most useful computer I own.

Here are seven setups — call them hacks, projects, or workflows — that made the biggest difference. All of them run headless, all of them survive reboots, and none of them required more than an afternoon to build.

1. The Network Watchdog That Reboots My Router

My ISP's router hangs roughly once a week. Instead of noticing the outage and fixing it by hand, the Pi notices for me. A cron job pings a couple of reliable hosts every five minutes; if both fail three times in a row, it toggles a smart plug via a local API and waits for the router to come back.

# watchdog.py — runs every 5 min via cron
import subprocess, requests, time

def internet_ok():
    for host in ["1.1.1.1", "9.9.9.9"]:
        try:
            subprocess.run(["ping", "-c1", "-W2", host],
                           check=True, capture_output=True)
            return True
        except subprocess.CalledProcessError:
            continue
    return False

fails = int(open("/tmp/watchdog_fails").read() or "0") if True else 0
# ... persist fail count, trip smart plug at 3 consecutive failures

Since deploying this, my household has had exactly zero "internet is down and nobody knows" moments.

2. An Ad-Hoc DNS Sinkhole for the Whole LAN

Install Pi-hole on the Pi, point your router's DHCP DNS at it, and every device on the network gets ad blocking for free. That's the standard setup. The hack part: I feed it a cron job that merges community blocklists with my own — any domain that appears in my web server access logs more than 50 times a day from bots gets auto-blacklisted. The Pi defends its own attention budget.

3. The "Digital Tripwire" With a Webcam

An old USB webcam + OpenCV gives you a motion-detecting security camera in about 30 lines. The trick that makes it actually useful: instead of streaming video, the Pi only wakes fully when motion crosses a threshold, captures a burst of frames, and pushes them to me via a Telegram bot. Idle power stays low, and I get a photo instead of a firehose.

import cv2
cap = cv2.VideoCapture(0)
prev = None
while True:
    ok, frame = cap.read()
    if not ok: continue
    gray = cv2.resize(cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY), (64, 48))
    if prev is not None and cv2.absdiff(gray, prev).mean() > 25:
        send_snapshot(frame)   # Telegram bot API call
    prev = gray

4. Overnight AI Recon on a Schedule

This is where the Pi stops doing chores and starts doing knowledge work. Every night at 2am, a cron entry kicks off an agent loop that checks my inbox, reads RSS feeds, scans security advisories for software I actually run, and writes a morning briefing as markdown. I read it with coffee; the Pi did the reading at 2am.

The agent plumbing — LLM client with retries, checkpointing so a crash resumes instead of restarting, structured JSON outputs — is the exact stack that ships in my AI Agent Toolkit ($9, one-time). You can absolutely hand-roll all of it, but if you want the boring parts pre-built so you can focus on what the agent actually does, that's what it's for. It runs happily on a Pi 4 with 2GB of RAM because the heavy lifting happens in the cloud — the Pi just orchestrates.

5. Automated Backup Sentry

The Pi runs my restic backups to two destinations: a USB drive and an offsite B2 bucket. The hack isn't the backup script — it's the verification job. Weekly, it restores a random file from last week's snapshot and checks the hash. Backups you've never restored are just optimistic fiction; this turns mine into tested fact. Failures (and successes) land in the morning briefing from hack #4.

6. Bug Bounty Recon on a Timer

Security researchers know the drill: subdomain enumeration, port scanning, screenshot capture. Doing it manually is a waste of a human. My Pi runs the same four-stage pipeline every night against targets I'm authorized to test — asset discovery, passive fingerprinting, change detection against yesterday's results, and a diff report. New subdomains show up in my inbox before breakfast.

The full pipeline, with every script and config, is documented step by step in my Bug Bounty Automation Kit — a $15 tutorial + toolkit. The Pi's low power draw matters here: recon is a waiting game, and a machine that costs pennies per month can afford to be patient.

7. The Pi That Monitors Itself

Meta, but essential: a tiny daemon logs CPU temperature, memory, disk usage, and every cron job's exit status to SQLite. A nightly query flags anything anomalous. My Pi has warned me about a filling SD card and a runaway script twice now — both times before anything broke. If you run any of the above, build this first.

The Bigger Picture

Every one of these follows the same pattern: cheap hardware + cron + a little Python beats paying for a service or doing it by hand. The Pi isn't powerful, and that's the feature — it forces lean, focused automation, and it never sends you a bill.

All of the source for these setups lives in my agent store repo, and the two kits linked above are the deepest dives if you want to go further.

Which one are you building first? I'd start with #1 or #5 — both take under two hours and pay off immediately.

10 Boring AI Automation Tricks That Keep My Agents Running for Months

ULNIT — Thu, 20 Aug 2026 01:03:13 +0000

I've spent the last year building small AI automations that actually run unattended — on a Raspberry Pi, a cheap VPS, and my laptop. Most AI automation content shows you the fun part (a prompt, a demo, a wow moment). Almost none of it shows you the part that decides whether the thing survives contact with reality.

Here are the tips and tricks that made the difference between scripts that die in a week and automations I haven't touched in months. Every one of these is boring. That's the point.

1. Never let the model be the only thing holding state

The #1 reason agent scripts fail: they keep state in memory or in the conversation, and when the process dies, everything is gone. Write every step to disk — SQLite is perfect for this. If your automation can answer "what was I doing, and what's left?", it can survive restarts, crashes, and reboots. On my Pi, every agent writes a checkpoint before and after each tool call. If it dies mid-run, the next invocation resumes instead of starting over.

2. Wrap every LLM call like it's an unreliable API

Because it is. Your wrapper needs: retries with exponential backoff, a timeout, token/usage accounting, and a fallback. I keep a tiny LLMClient class that does all four. Ten lines of retry logic has saved me more times than any clever prompt. If you're rolling agents by hand, this is also exactly the kind of plumbing I packaged up in the AI Agent Toolkit — the client, the agent loop, logging, and config as clean Python modules, $9 one-time. But you can (and should) build your own first; you'll understand it better.

3. Structure your outputs, don't parse prose

Never ask the model to "write a report" and then regex the result. Ask for JSON with an explicit schema, validate it, and retry on failure. I use a small validation loop: request JSON, attempt to parse, if it fails feed the error back to the model once. Two tries is almost always enough. Structured output turns a flaky text generator into a reliable data source.

4. Give tools tight contracts and narrow permissions

An agent that can "run any shell command" is a liability, not a feature. Give it specific tools: list_subdomains, fetch_url, write_report. Each tool has a defined input and output. Narrow tools are easier to test, easier to log, and much safer. This is the core idea behind the recon pipeline in my Bug Bounty Automation Kit — enumeration, scanning, and triage as discrete, auditable steps rather than one black-box "agent."

5. Log like you'll be debugging at 3 AM

You will be. Log the prompt, the raw response, the tool calls, and the timing — but log them to structured files (JSONL), not just stdout. Then a quick jq query tells you exactly where things went sideways. Timestamp everything. On a headless Pi with no monitor, your logs are your eyes.

6. Schedule with cron, not cleverness

People reach for Kubernetes and message queues for things that cron handles perfectly. A single crontab line plus a systemd timer for retries covers 95% of "run this every night" needs. Keep the scheduler dumb and the script robust. Complexity is a cost; spend it only where it earns its keep.

7. Make the last step a human-readable report

The best trick I learned: end every automation with a step that produces a short, readable summary — a markdown file or an email. Not a dashboard. Not a metric. One paragraph of "here's what I did and what I found." It turns a background process into something you actually check, which is how you notice problems early. My recon runs end with a markdown report that's genuinely pleasant to read.

8. Run it on weak hardware on purpose

If your automation runs on a Raspberry Pi with 2 GB of RAM, it runs anywhere. I test everything on the Pi first. It forces small memory footprints, honest about resource use, and it catches assumptions about speed and availability that would hide on a beefy machine.

9. Version your prompts and configs like code

Put prompts, model names, and thresholds in a config file, and commit it to git. When output quality changes, you can bisect. "It worked last Tuesday" is a solvable problem when your prompts are versioned; it's a mystery when they're inline strings.

10. Ship boring, fix clever

Get the dumb-but-reliable version running end to end before you optimize. A pipeline that produces mediocre results every single night is infinitely more valuable than a brilliant one that runs when it feels like it. You can improve quality later; you can't improve a thing that isn't running.

That's the whole playbook. None of it is exciting, and all of it compounds: state on disk, retries, structured output, tight tools, honest logging, dumb scheduling, readable reports, weak-hardware testing, versioned configs, and boring-first shipping.

Stack those ten habits and your AI automations stop being demos and start being infrastructure. Happy building.

I Spent a Week Testing the $9 AI Agent Toolkit — Here's What's Actually Inside

ULNIT — Wed, 19 Aug 2026 01:02:42 +0000

A week ago I picked up the AI Agent Toolkit — a $9 bundle of pre-built automation agents — mostly out of curiosity. Nine dollars is coffee money, so my bar was low: if one component saved me an afternoon, it paid for itself. After a week of actually running it on a Raspberry Pi 5 and a spare laptop, here's an honest breakdown of what's inside, what works, and what you should know before you buy.

What the Toolkit Actually Is

The toolkit is a collection of Python-based automation agents and the scaffolding to run them: task runners, prompt templates, state management, and a small framework for chaining agents together. It's not a hosted SaaS — everything runs on your own hardware, which I like. My Pi 5 (8 GB) handled the full stack with plenty of headroom.

The core pieces:

Agent runner — a lightweight loop that takes a task definition, calls an LLM, executes tool calls, and tracks state between runs.
Prompt + workflow templates — pre-written scaffolds for common jobs: summarization, triage, data extraction, report generation.
Integration glue — connectors for email, RSS, webhooks, and Telegram, which is where most of the practical value lives.
State store — a simple SQLite-backed dedup layer so agents never process the same item twice.

What I Built With It in a Week

Day 1–2: Inbox triage. I pointed the email agent at a secondary inbox that gets ~120 messages a day. It classifies into "act today", "FYI", and "noise", then sends me a Telegram digest at 7 AM. Accuracy was honestly better than I expected — around 90% on the first day, and better after I tweaked the classification prompt. The template got me 80% of the way there; the last 20% was prompt tuning, which is exactly how it should be.

Day 3–4: RSS synthesis. ~35 feeds, deduplicated, summarized overnight. The state store is the unsung hero here — without it, every agent framework I've tried eventually re-summarizes the same story from three outlets. This one didn't.

Day 5–7: chaining. The interesting part. I wired the triage output into the report agent, so anything marked "act today" automatically lands in a daily action list. Chaining agents is just YAML-style task definitions pointing at each other — no message broker, no Kubernetes, nothing. It's deliberately small, which is its biggest strength.

The Good, The Meh, and The Honest Caveats

The good:

It's real, runnable code — not a Notion doc of prompts. You can read it, fork it, and extend it.
Runs entirely self-hosted. Your API keys, your hardware, your data.
The boring parts (state, dedup, retries, scheduling) are already solved, and those are the parts nobody wants to write.
At $9, the risk-reward ratio is almost silly.

The meh:

Documentation is functional but thin in spots. I had to read the source to understand a couple of config options — fine for me, potentially annoying if you're newer to Python.
It assumes you're comfortable with the command line. There's no GUI, and that's a deliberate choice.

The caveats:

You still bring your own LLM API key, so there's an ongoing cost (mine runs about $0.10/day for the whole pipeline).
It won't magically build novel automations for you — it's a toolkit, not a genie. The value is skipping the plumbing, not skipping the thinking.

Who Should (and Shouldn't) Buy It

Buy it if you want working agent scaffolding you can deploy on your own hardware this weekend, you're comfortable with Python basics, and you'd rather adapt real code than write a framework from scratch. For $9, even one working pipeline is a win.

Skip it if you want a no-code, point-and-click product — this is a builder's toolkit, and the audience is people who like reading the source anyway.

Final Verdict

The AI Agent Toolkit earned its keep in my setup by day three. It's not magic — it's well-organized, self-hosted automation code that removes the 80% of agent-building that's pure boilerplate. If you've been meaning to run your own agents but keep getting stuck on the scaffolding, this is a cheap way to unstick yourself.

Full disclosure: I'm a fan of the project and may earn a commission on the link above. Everything in this review reflects a week of actual use on my own hardware.

If you build something with it, I'd genuinely like to hear what — drop a comment.

How I Built an AI Agent That Reads the News and My Inbox Before I Wake Up

ULNIT — Tue, 18 Aug 2026 01:02:22 +0000

How I Built an AI Agent That Reads the News and My Inbox Before I Wake Up

For years my morning routine was the same: reach for the phone, open email, open a few news sites, and lose 40 minutes to a mix of newsletters I didn't care about and headlines designed to spike my cortisol. By the time I actually sat down to work, the best part of my focus was gone — spent on information that, honestly, an intern could have filtered for me.

So I built the intern. An AI agent, running on a Raspberry Pi sitting on my desk, that reads everything for me overnight and hands me a one-page digest with my coffee. This is the story of how I built it, what broke, and what I'd do differently.

The Goal

I wanted three things:

Inbox triage — sort email into "act today", "FYI", and "noise" before I see it.
News synthesis — follow ~40 RSS sources and summarize only what's genuinely new, deduplicated across outlets.
One artifact — a single markdown digest delivered to Telegram at 6:30 AM. No apps to open, no feeds to scroll.

The hard part isn't any of these individually. It's doing them reliably, cheaply, and without the agent hallucinating a news story that doesn't exist.

The Architecture

The pipeline is deliberately boring:

[IMAP + RSS collectors] → [dedup/state store] → [LLM triage agent] → [digest renderer] → Telegram

Everything runs on cron. The collectors are dumb scripts; the LLM only ever sees new items since yesterday's run. That single decision — never re-send the full dataset to the model — keeps the whole thing under ~$0.10/day in API costs.

The collectors are straightforward Python:

import imaplib, email, feedparser, json, hashlib

def fetch_unseen_emails(since_hours=24):
    mail = imaplib.IMAP4_SSL("imap.gmail.com")
    mail.login(EMAIL, APP_PASSWORD)
    mail.select("INBOX")
    _, data = mail.search(None, "UNSEEN")
    items = []
    for num in data[0].split():
        _, msg = mail.fetch(num, "(RFC822)")
        m = email.message_from_bytes(msg[0][1])
        items.append({
            "id": hashlib.sha1(num).hexdigest(),
            "from": m["From"],
            "subject": m["Subject"],
            "body": str(m.get_payload())[:1500],
        })
    return items

def fetch_feeds(urls):
    items = []
    for url in urls:
        for e in feedparser.parse(url).entries[:10]:
            items.append({
                "id": hashlib.sha1(e.link.encode()).hexdigest(),
                "title": e.title,
                "summary": e.get("summary", "")[:800],
                "link": e.link,
            })
    return items

A state file tracks which item IDs have already been processed, so the agent only triages fresh material.

The Agent Layer

This is where most DIY versions fall apart. My first attempt handed the LLM a wall of text and said "summarize this." The result was bland, generic, and occasionally invented connections between stories that didn't exist.

What actually works is constraining the agent hard:

Structured output only. Each item must be classified (act_today / fyi / noise for email, read / skip for news) with a one-line justification.
No synthesis across items. The agent summarizes each item independently; I do the connecting. This killed hallucinations almost entirely.
A scoring rubric in the prompt. "Relevant to: self-hosting, security research, LLM tooling, Raspberry Pi. Everything else is noise unless it's genuinely major."

PROMPT = """You are a triage agent. For each item below, return JSON:
{verdict: "act_today"|"fyi"|"noise"|"read"|"skip", reason: "<10 words"}
Relevance rubric: self-hosting, security research, LLM tooling,
Raspberry Pi. Be ruthless — default to noise/skip."""

The digest renderer then groups verdicts into sections and sends the markdown to Telegram via the bot API. Total runtime: about 3 minutes per morning.

What Broke (and What I'd Do Differently)

Rate limits. My first version fired one API call per item. Batching items into groups of 10 cut cost and latency by 80% with no quality loss.

Feed noise. Some RSS feeds duplicate stories across categories. Deduplicating by title similarity (a quick difflib ratio check) before the LLM stage saved a third of the tokens.

Plumbing vs. thinking. Here's my honest takeaway: the interesting 20% of this project was the prompt engineering and the triage rubric. The other 80% — collectors, state management, retries, scheduling, output formatting — is solved plumbing you should not hand-roll. I ended up rebuilding the scaffolding on top of the AI Agent Toolkit, a $9 set of ready-made agent patterns and scripts that gave me the collector/state/delivery boilerplate in an afternoon. If you're building something like this, starting there is the difference between a weekend project and a month of yak-shaving. The same skeleton, incidentally, powers my security monitoring too — the Bug Bounty Automation Kit is the same idea pointed at recon pipelines instead of inboxes.

The Result

My screen time in the first hour of the day dropped from ~40 minutes to ~5. The digest is one Telegram message: five emails that actually need answers, six stories worth reading, nothing else. Some days the "noise" bucket has 60 items and I feel zero guilt ignoring it.

The bigger lesson: agents aren't magic, they're interns. They're brilliant when you give them a rubric, a narrow scope, and a format to fill in — and useless when you hand them ambiguity. Design the constraints first; the intelligence takes care of itself.

If you build one of these, start small: ten feeds, one inbox, one delivery channel. You can always widen the aperture once the intern stops making things up.

I Let an AI Agent Run My Bug Bounty Recon Overnight — Here's the Setup That Actually Works

ULNIT — Mon, 17 Aug 2026 01:02:48 +0000

I Let an AI Agent Run My Bug Bounty Recon Overnight — Here's the Setup That Actually Works

Last month I was spending my evenings doing the most boring part of bug bounty hunting by hand: running subfinder, httpx, and nuclei against targets, copy-pasting results between terminal windows, and babysitting a laptop that needed to stay awake. The actual interesting part — reading responses, spotting weird endpoints, testing hypotheses — kept getting pushed to "tomorrow."

So I automated the boring part. All of it. The agent I ended up with runs on a Raspberry Pi, costs less than a coffee to operate, and hands me a triaged report every morning. Here's how it works.

The Core Idea

Most automation tutorials stop at "here's a bash script with a cron job." That's fine for fixed pipelines, but bug bounty targets move: new subdomains appear, services change ports, an endpoint that returned 404 yesterday starts returning 200 today. A static script can't decide that a newly-exposed debug panel on a staging subdomain is worth escalating and a CDN edge is not. An agent can.

The architecture is three layers:

Collectors — dumb, reliable scripts that gather raw data (subdomains, live hosts, ports, response hashes).
Diff engine — compares today's snapshot against yesterday's. Everything unchanged gets discarded.
Agent layer — an LLM agent that only ever sees the diff, classifies each change, and decides what deserves deeper probing.

The agent never touches the full dataset. That's the trick that keeps API costs sane and keeps the agent focused.

The Pipeline in Practice

# collectors run at 02:00, diff at 04:00, agent at 05:00
0 2 * * * /opt/recon/collect.sh >> /var/log/recon/collect.log 2>&1
0 4 * * * python3 /opt/recon/diff.py --state /data/state.json
0 5 * * * python3 /opt/recon/agent_triage.py --input /data/todays_diff.json

The collectors are the usual suspects:

import subprocess, json

def collect_subdomains(target):
    out = subprocess.run(["subfinder", "-d", target, "-silent"],
                         capture_output=True, text=True)
    return set(out.stdout.splitlines())

def probe_live(subdomains):
    out = subprocess.run(["httpx", "-silent", "-status-code", "-title"],
                         input="\n".join(subdomains),
                         capture_output=True, text=True)
    return out.stdout.splitlines()

The diff engine writes out JSON with three buckets: new_assets, changed_responses, and gone_assets. Gone assets are underrated — a subdomain suddenly disappearing often means it's about to become dangling and takeable over.

The agent then gets a prompt roughly like: "Here are 14 changes since yesterday. For each, output a JSON verdict: IGNORE, WATCH, or INVESTIGATE, plus a one-line reason. You have access to a tool that fetches a URL and returns headers + first 500 bytes."

It's shocking how well this works. It correctly flagged a /graphql endpoint that appeared on a marketing subdomain as INVESTIGATE and waved through forty "server header changed" noise items as IGNORE. That triage pass used to take me an hour of scrolling.

Why a Raspberry Pi?

This whole stack idles at a few hundred megabytes of RAM. A Pi 4 or 5 runs the collectors, the state database, and the agent orchestrator without breaking a sweat, draws a few watts, and never needs to be "on" as a separate decision — it's just always there. I've got mine headless on my desk doing recon every night while I sleep. The only thing that isn't local is the LLM call for triage, and because it only sees the diff, a typical night costs pennies in tokens.

The one operational lesson: keep your state in a real database (I use SQLite), not flat files. The night a collector crashed mid-write, flat-file state silently corrupted and the diff engine reported 2,000 "new" subdomains. SQLite transactions made that class of bug impossible.

The Part That Took Me Too Long to Figure Out

Rate-limit yourself before the target does. Run httpx with -rl 10, spread collectors across the night, and never parallelize nuclei templates that send writes. The goal is to look like the most polite scanner that ever existed. Bonus: slower, spaced-out requests catch flaky endpoints that fast bursts miss.

If You Don't Want to Build It From Scratch

Honestly, building this from scratch was a weekend of plumbing, not hacking. The interesting work was designing the agent's verdict schema and testing it against real diffs. If you'd rather skip the plumbing, the Bug Bounty Automation Kit packages up exactly this pattern — collectors, diffing, and agent triage wired together for $15, which is less than one hour of my time used to cost me. It's what I started from before customizing it, and it drops straight onto a Pi. If your targets are more general automation than bug bounty, the AI Agent Toolkit ($9) covers the same agent-loop fundamentals for broader use cases. More resources in the agent store.

Start Tonight

Get subfinder, httpx, and nuclei running against one target, manually.
Add the diff layer — even a JSON file in git works at first.
Put an LLM call in front of the diff and iterate on the verdict prompt until it stops hallucinating interest in CDN noise.

Then sleep in. The morning report will be waiting.

What's the most boring part of your recon that you haven't automated yet? That's your next project.

5 Raspberry Pi Automation Builds That Pay for Themselves

ULNIT — Sun, 16 Aug 2026 01:02:57 +0000

A Raspberry Pi is the most underrated automation hardware you can buy. It costs about the same as a pizza, sips 2–5 watts, runs a full Linux stack, and exposes GPIO pins for when you want to touch the physical world. I've been running Raspberry Pis as always-on automation boxes for years — scraping, monitoring, alerting, and orchestrating AI agents — and these are the five builds that have proven most worth the effort, plus what I've learned keeping them alive 24/7.

Why a Pi beats a cloud VM for personal automation

Most personal automation is small: a handful of cron jobs, a few HTTP requests a minute, a few megabytes of logs a day. For workloads like that, a Pi wins on three fronts:

Cost: a one-time $35–75 instead of $5–10/month forever. It pays for itself inside a year.
Privacy: your scraping history, credentials, and data never leave your network.
Control: root access, systemd, GPIO, no hypervisor restrictions. If you can do it on Linux, you can do it on a Pi.

The catch is reliability. SD cards die, cheap power supplies sag, and memory leaks compound. Every build below assumes the boring basics are handled: a quality power supply, a high-endurance microSD card (or better, USB SSD boot), and services managed by systemd instead of scripts left running in a tmux session.

Build #1: The web watchdog

The gateway drug of Pi automation: a Python script that polls a list of URLs, hashes the responses, and pushes a notification when anything changes. Price trackers, release monitors, "is this expired domain still available" checkers — same loop every time. The trick is to diff meaningfully: hash extracted text content, not raw HTML, or you'll get 3 a.m. alerts because a cache-buster parameter changed.

Build #2: DNS-level automation for your whole network

Run a DNS sinkhole on the Pi and suddenly your automation covers every device in the house. Log every query, block ad and tracker domains, and wire up alerts for anomalies — like an IoT device phoning home to a country you've never heard of. That single alert has caught misbehaving smart devices for me more than once. The Pi's low power draw makes it a perfect always-on DNS server.

Build #3: AI agents on a schedule

A Pi 5 has plenty of muscle to orchestrate LLM-powered agents. It won't run big local models well, but it's excellent as the orchestration layer: a cron job fires, the script calls an LLM API, the agent does research, writing, summarizing, or triage, and the result lands in your inbox, a file, or a webhook. One of mine runs every morning, digests my overnight alerts, and messages me a summary. The plumbing for agent jobs is mostly boilerplate — which is why I packaged mine up. If you want a starting point, my AI Agent Toolkit ($9) includes the scheduling patterns, prompt templates, and glue code I use on my own Pi fleet.

Build #4: The bug bounty recon box

Recon is 90% of bug bounty hunting, and it's almost entirely automatable: subdomain enumeration, port scans, screenshotting, technology fingerprinting. A Pi makes a great dedicated recon box — it's slow, but it runs forever, and its natural rate-limiting actually keeps you polite to your targets. Point it at your authorized scope overnight and wake up to a fresh report. I wrote up my complete pipeline in my Bug Bounty Automation Kit ($15), including the exact toolchain and how to keep everything legal and in-scope.

Build #5: Touch the physical world

GPIO is where the Pi stops being a tiny server and becomes a hack. Relay boards and ten dollars get you control of lights, fans, or a door strike. A $3 motion sensor becomes a security tripwire that snaps a camera frame and pushes it to your phone. My favorite: a reed switch on the mailbox that logs every delivery. None of it requires more than a few lines of Python and the gpiozero library.

Keeping a Pi alive for years

Three lessons from fleet members with 400+ day uptimes:

systemd + auto-restart. Restart=always plus a watchdog timer means crashes self-heal.
Log to RAM. Point chatty logs at tmpfs or silence them, and your SD card lives years longer.
Monitor the monitor. Dead automation is silent. Have a second system — even another Pi — ping your services and scream when they stop answering.

The bottom line

A $35 board, a few Python scripts, and an afternoon of setup buys you infrastructure that would cost $20+ a month in the cloud — and it all stays on your terms. Start with one watchdog script and let the ideas compound from there.