DEV Community: Patrick Hughes

We Built Fowler's AI Feedback Flywheel (Before He Named It)

Patrick Hughes — Fri, 10 Apr 2026 02:32:55 +0000

We Built Martin Fowler's AI Feedback Flywheel Before He Named It

On April 9, 2026, Martin Fowler published a detailed article describing a pattern he calls the Feedback Flywheel — a system for converting individual AI interactions into collective team improvement.

We'd been running the same system for months.

Not because we copied it. We hadn't read the article yet. We built it because it was the obvious solution to a real problem: every AI interaction generates useful signal, and almost every team throws that signal away.

What Fowler Describes

Fowler's Feedback Flywheel has two layers: signal types and shared artifacts.

The four signal types:

Context signals — facts about your codebase, domain, or project that the AI needs
Instruction signals — prompts and phrasings that reliably produce good output
Workflow signals — multi-step sequences that work well end-to-end
Failure signals — cases where the AI did something wrong

Those signals feed into four shared artifacts:

Priming docs — shared context files the whole team pulls into every session
Commands — reusable prompt templates anyone can invoke
Playbooks — documented workflows for recurring tasks
Guardrails — explicit constraints that prevent known failure modes

The cadence: after each session, at standup, at retro, quarterly. Key metric: declining instances of "why did the AI do that?"

What We Built

Our implementation lives across three systems: the Obsidian vault, the autotron agent network, and AgentGuard.

Layer 1: The Vault (Signal Capture)

Every meaningful AI interaction — good or bad — gets logged. The vault has a structured Feedback/ directory that captures what the prompt was, what the output was, whether it worked, and what to do differently.

This maps directly to Fowler's four signal types. Context signals become context/ files read by every agent at startup. Failure signals become guardrails. The difference: ours is machine-readable, not just human-readable. Agents ingest these files. They're runtime configuration, not documentation.

Layer 2: The Agent Network (Signal Processing)

The autotron system runs scheduled agents: CMO, CFO, standup, deal monitor, market scout. Each agent:

Reads shared context files at startup
Executes its task
Writes findings back to shared memory
Updates queue files that other agents read on their next run

Signal captured → shared artifact updated → next agent reads it → better output

Every cycle, the system knows a little more. Every agent run improves the baseline.

Layer 3: AgentGuard (The Guardrail Layer)

Fowler's "failure signal → guardrail" step is the hardest to implement in practice. Most teams write notes after an agent goes wrong. Notes don't stop the next agent from making the same mistake.

AgentGuard enforces hard constraints at runtime:

from agentguard import Guard

guard = Guard(
    budget_limit=5.00,    # hard stop at $5
    token_limit=100_000,  # no runaway context
    time_limit=300,       # 5 min max
)

@guard.protect
def run_agent():
    # your agent logic here
    ...

When a new failure mode is discovered, a new guard condition gets added. The system can't repeat the same expensive mistake twice.

Install: pip install agentguard47

The Weekly Cadence

Cadence	Fowler's Artifact	Our Implementation
After each session	Priming doc update	Vault feedback log + context file update
Daily	Standup signal review	Autotron standup agent writes to shared memory
Weekly	Retro + playbook update	Weekly review agent updates SKILL.md files
Quarterly	Strategy refresh	CFO + CMO quarterly review

What to Build First

Week 1: Create a shared context file. One document everyone pulls into every AI session. Put your domain glossary, common workflows, and "don't do this" notes in it.

Week 2: Build a failure log. When an AI output goes wrong, write down what happened. After 10 entries, you'll see patterns. Turn those patterns into constraints.

Week 3: Add a budget guardrail. Hard spend limit before agents touch production.

Week 4: Run a retro on your AI tooling. What prompts are people reusing manually? Turn them into shared commands. What workflows run every week? Turn them into scheduled agents.

By week 4 you have the skeleton of a Feedback Flywheel. It compounds from there.

Originally published at bmdpat.com. If you want help designing this kind of compounding AI infrastructure for your team, start here.

How Much Does It Cost to Build an AI Agent? (2026 Pricing)

Patrick Hughes — Fri, 10 Apr 2026 02:31:35 +0000

How Much Does It Cost to Build an AI Agent in 2026?

Building an AI agent costs anywhere from $500 to $150,000+ depending on complexity. That's a useless range until you understand what drives the cost. Here's the real breakdown.

Most projects fail estimates not because the AI is expensive — LLM APIs are cheap. They fail because teams undercount the engineering work, skip the error handling, and discover 90% of the complexity after they start.

Cost by Complexity Tier

Tier	What It Does	Build Cost	Timeline
Simple	Single tool, FAQ bot, one-step automation	$500–$3,000	1–2 weeks
Moderate	3–5 tool integrations, conditional logic, CRM/API connections	$3,000–$15,000	2–4 weeks
Complex	Autonomous loops, memory, multi-step reasoning, error recovery	$15,000–$50,000	4–10 weeks
Enterprise	Multi-agent orchestration, custom fine-tuning, SLA requirements	$50,000–$150,000+	3–6 months

These are build-only costs — design, development, testing, and deployment. Ongoing API and hosting costs are separate.

The 4 Cost Buckets

Every AI agent project has the same four cost drivers. Most teams only budget for the first one.

1. API Costs (Usually the Smallest Bucket)

LLM APIs are cheaper than you expect:

Claude Sonnet: $3/M input tokens, $15/M output tokens
GPT-4o: $5/M input tokens, $15/M output tokens

For a moderate-use agent (500 calls/day, ~10K tokens per call): $150–$400/month

Use Claude's Batch API for async tasks — it cuts API costs by 50%. Prompt caching saves another 60–80% on repeated system prompts.

2. Compute Costs

If you're using cloud LLM APIs (most teams are), compute is just your hosting bill:

Serverless (Lambda, Vercel Functions): $10–$100/month for light agents
Containerized (Docker + VPS): $50–$300/month
Kubernetes cluster: $300–$2,000/month

3. Development Time (The Biggest Variable)

An "AI agent" isn't just API calls — it's architecture design, prompt engineering, tool integrations, error handling, and testing. First versions hallucinate. Budget for 3–5 rounds of refinement.

Dev time by tier at $150–$250/hour:

Tier	Engineering Hours	Cost at $150/hr	Cost at $250/hr
Simple	10–20 hrs	$1,500–$3,000	$2,500–$5,000
Moderate	40–80 hrs	$6,000–$12,000	$10,000–$20,000
Complex	100–200 hrs	$15,000–$30,000	$25,000–$50,000
Enterprise	300–600+ hrs	$45,000–$90,000	$75,000–$150,000

4. Hosting and Infrastructure

For most small-to-mid agents: budget $100–$400/month ongoing.

Build vs. Buy: When Each Makes Sense

Buy (platform) if:

Your use case is standard (support bot, scheduling, doc extraction)
You have no custom integrations
Budget is under $500/month for tools

Build (custom) if:

Your workflow is the edge case — platform tools don't cover it
You need deep CRM/ERP integration with business logic
Security, compliance, or data residency requirements
You want to own the code and iterate without vendor lock-in

Why Most Teams Overpay

Scoping to capabilities, not jobs. Each feature addition multiplies complexity nonlinearly.
Ignoring error handling. Agents fail. APIs return 500s. LLMs go off-rails. This takes real time.
No cost controls. Without runtime budget enforcement, a loop bug can generate $2,000 in API charges in under an hour.
Agency markup. Most AI agencies charge 3–5x the actual work cost.
Treating iteration as failure. Budget for two or three rounds of refinement — that's not waste, that's how agents get reliable.

The Flat-Rate Alternative

At bmdpat.com, I build AI agents at fixed prices:

Simple agent (one tool, clear scope): $2,000
Moderate agent (3–5 integrations, conditional logic): $3,500
Complex agent (autonomous behavior, memory, research loops): $5,000–$7,500

Fixed price. You know the cost before we start. Every agent ships with budget enforcement built in.

Get a fixed price for your agent →

Originally published at bmdpat.com

AI Agent Cost in 2026: $500 to $150K — Real Pricing Breakdown

Patrick Hughes — Fri, 10 Apr 2026 02:30:05 +0000

How Much Does It Cost to Build an AI Agent in 2026?

If you're Googling this, you're probably comparing options. Let me give you real numbers instead of "it depends" or "let's schedule a call."

The Short Answer

Type	Price Range	Timeline
Simple workflow automation	$500–$1,000	3-5 days
Custom AI agent (single task)	$2,000–$3,500	1-2 weeks
Complex autonomous agent	$3,500–$5,000	2-3 weeks
Enterprise multi-agent system	$5,000–$15,000+	3-6 weeks

These are MY prices — an independent builder with low overhead. Agency prices are typically 3-5x higher.

What Drives the Cost

1. Complexity of Decision-Making

An agent that follows a fixed flowchart (if X then Y) is cheap. An agent that needs to reason about ambiguous inputs, handle edge cases, and make judgment calls costs more.

$500 example: "When a new row appears in this spreadsheet, classify it and route it to the right person"

$5,000 example: "Read incoming support tickets, understand the problem, search our knowledge base, draft a response, and escalate if confidence is low"

2. Number of Integrations

Each API connection adds complexity. An agent that talks to 2 systems is simpler than one that orchestrates 8.

1-2 integrations: baseline cost
3-5 integrations: +$500-1,000
6+ integrations: +$1,000-2,000

3. Reliability Requirements

A personal tool that fails occasionally is fine. A production system handling customer data needs error handling, retries, logging, and monitoring.

Personal/internal tool: baseline
Customer-facing: +30-50% for reliability engineering

4. AI Model Costs

The agent itself has ongoing costs:

Model	Cost per 1K tokens	Typical monthly cost
Claude Haiku	$0.00025	$5-20/mo
Claude Sonnet	$0.003	$20-100/mo
GPT-4o	$0.005	$30-150/mo
GPT-4o mini	$0.00015	$3-15/mo

Most agents cost $10-50/month in API calls. Heavy usage might hit $100-200/month. For high-volume, repeatable tasks, running inference locally on a consumer GPU can bring this to near zero.

What You're Actually Paying For

When I quote $3,000 for an AI agent, here's the breakdown:

Discovery & scoping (2-3 hours): Understanding your workflow, defining success criteria
Architecture (2-4 hours): Choosing the right model, designing the agent loop, planning error handling
Implementation (15-25 hours): Writing the code, building integrations, prompt engineering
Testing (5-10 hours): Edge cases, failure modes, load testing
Documentation & handoff (2-3 hours): How to use it, how to maintain it, how to modify it

How to Reduce Costs

Start small — Automate one workflow, not your entire operation
Use existing tools — n8n + AI nodes is cheaper than a custom build for simple workflows
Define clear success criteria — vague requirements = expensive scope creep
Provide clean data — messy inputs require more error handling code
Accept async delivery — meetings waste everyone's time and money

Red Flags in Pricing

Be skeptical if someone quotes:

Under $500 for a "custom AI agent" — it's probably a wrapper around ChatGPT with minimal engineering
Over $20,000 without a clear spec — enterprise pricing for SMB work
Monthly retainer before proving value — you should see results before committing to ongoing costs
"We need a discovery phase first" — translation: "we don't know what we're doing yet and want you to pay for our learning curve"

My Pricing Philosophy

Flat rate — you know the cost before I start
No retainers — pay per project, not per month
Async delivery — no meetings means lower overhead means lower prices
You own everything — code, documentation, infrastructure

ROI Calculator

If your manual workflow takes X hours per week at $Y/hour:

Annual cost of doing it manually: X × Y × 52

Example: 5 hours/week at $40/hour = $10,400/year in manual labor

A $2,500 agent that eliminates this work pays for itself in 12.5 weeks.

Originally published at bmdpat.com. Ready to get a real quote? Start a project — I'll reply in 24 hours with a fixed price.

OpenClaw vs Custom AI Agents: Which Saves More in 2026?

Patrick Hughes — Fri, 10 Apr 2026 02:28:40 +0000

OpenClaw Has 250K GitHub Stars — But Should Your Business Actually Use It?

OpenClaw just crossed 250,000 GitHub stars — a milestone that took the Linux kernel years to reach. NVIDIA announced NemoClaw at GTC 2026 to bring it into the enterprise stack. And every developer on your timeline is posting their OpenClaw setup.

It's the fastest-growing open-source AI agent framework in history. And for good reason — it's genuinely powerful.

But if you're a business owner looking at OpenClaw and thinking "this is how I automate my operations," you need to understand what it actually is, what it's good at, and where the gap between demo and production gets expensive.

What OpenClaw Actually Does

OpenClaw is an open-source server that runs locally on your machine and acts as the brain of a personal AI agent. You connect it to an LLM (Claude, GPT, DeepSeek, or a local model via Ollama), and it can interact with your computer through a plugin system called "skills."

These skills let the agent control web browsers, manage files, send messages, hit APIs, and automate multi-step workflows. It has 100+ prebuilt skills and the community is building more every day.

Think of it as the operating system for AI agents.

Where OpenClaw Excels

For individual developers and power users, OpenClaw is incredible. If you want to automate your personal workflow — research, file management, email triage, data processing — it's genuinely the best tool available right now at zero cost.

It runs locally, which means your data stays on your machine. No cloud dependency. No per-API-call costs beyond the LLM inference. If you're running a local model through Ollama on a consumer GPU, your total cost is electricity.

Where the Gap Appears for Businesses

Here's where it gets real. There's a meaningful difference between "I automated my personal workflow" and "this runs my business processes reliably."

1. OpenClaw requires technical setup and maintenance. Someone on your team needs to install it, configure skills, connect the right models, handle updates, and debug when things break.

2. No built-in governance or audit trails. OpenClaw agents can do anything the skills allow — but there's no built-in system for decision boundaries, approval workflows, or logging what the agent did and why. For business processes involving finances, customer data, or compliance-sensitive workflows, that's a liability.

3. Reliability at scale is your problem. OpenClaw is a framework, not a managed service. If it crashes at 2am during a critical workflow, there's no SLA, no support team, no rollback.

4. Integration depth varies. The 100+ skills cover common use cases, but your specific business probably has unique tools, APIs, and data formats. Custom integrations require development time.

The Real Decision Framework

The question isn't "OpenClaw or custom agent?" It's "what stage is your automation at?"

Use OpenClaw when:

You have a developer who can set it up and maintain it
The workflows you're automating are personal or internal
You're prototyping to figure out what's possible before investing
The stakes are low if something breaks

Go custom when:

The workflow touches customer data, finances, or compliance
You need guaranteed uptime and reliability
Nobody on your team can maintain it
You need audit trails and decision boundaries
The ROI justifies a one-time investment vs. ongoing maintenance

The hybrid approach (what I recommend):
Start with OpenClaw to prototype and validate. Figure out which automations actually save time and money. Then build production-grade custom agents for the workflows that matter most.

What I've Learned Building AI Agents on Consumer Hardware

I've been building autonomous AI agents on consumer GPUs (RTX 3070, RTX 5070 Ti, RTX 5090) for months — before OpenClaw went viral. The fundamental insight is the same one driving OpenClaw's growth: you don't need a datacenter to run powerful AI agents.

But the difference between a demo and a business tool is governance, reliability, and specificity. The agents I build for clients have decision boundaries, audit trails, and are scoped to exact workflows. They're not general-purpose — they're purpose-built to solve one specific problem really well.

That's the gap OpenClaw doesn't fill yet. And it's where the real business value lives.

The Bottom Line

OpenClaw is one of the most important open-source projects in AI right now. If you're a developer, you should absolutely be using it.

But for businesses looking to automate production workflows, "free and open-source" is the beginning of the cost conversation, not the end. The setup time, maintenance burden, and governance gaps add up — and they add up faster when something goes wrong.

Originally published at bmdpat.com.

Run LLMs on Consumer GPUs in Production (2026 Guide)

Patrick Hughes — Fri, 10 Apr 2026 02:26:50 +0000

Serving a Live LLM From My Home Office: What Local Inference in Production Actually Looks Like

I run a public LLM inference endpoint out of my home office. Right now, Llama 3.1 8B is loaded into an RTX 5070 Ti, quantized to Q4_K_M, serving streaming responses with real latency metrics. You can hit it on the lab page.

This isn't a tutorial assembled from docs. It's what I actually did, what broke, and when running local inference is worth the trouble.

Why Local Inference at All

The obvious question: why not just call the OpenAI API?

Three reasons that actually matter:

Cost at volume. For a business running thousands of LLM calls per day, API costs add up fast. A 7B or 8B local model handles a huge class of tasks — classification, extraction, summarization, short-form generation — at near-zero marginal cost after the hardware purchase.

Data privacy. If you're building something for healthcare, legal, or finance, sending data to a third-party API is a compliance risk. Local inference keeps everything on your iron.

Latency control. API providers have their own queue. Your GPU doesn't. For latency-sensitive applications, owning the inference layer matters.

The Stack

Hardware: RTX 5070 Ti (16GB GDDR7). This GPU hits a sweet spot — enough VRAM to run an 8B model with room for a reasonable context window, fast enough to generate responses that feel instant.

Runtime: llama.cpp. It's written in C++, runs everywhere, and has excellent CUDA support. It's not glamorous, but it works.

Model: Llama 3.1 8B at Q4_K_M quantization. This format cuts the model's memory footprint roughly in half vs. full float16, with minimal quality loss for most real-world tasks. At this quantization level, the whole model fits comfortably in 16GB VRAM with room left for context.

Server layer: llama.cpp's built-in server binary exposes an OpenAI-compatible REST API on localhost. That means any code written against the OpenAI SDK just works — you change the base URL, not the code.

What the Numbers Look Like

Context window: Llama 3.1 8B supports 128K tokens natively. In practice, I run it with a 32K window — enough for most real tasks without blowing VRAM on the KV-cache.

Concurrent requests: This is where a single consumer GPU hits its limit. You can handle a few simultaneous requests, but it's not vLLM. If you need high concurrency, you need a different setup.

When Local Inference Makes Sense

You're running high-volume, repeatable tasks. Extraction, classification, structured output generation. Anything where you're calling the model thousands of times and the per-call cost adds up.

Your data can't leave the building. Medical records, legal documents, financial data. Local inference is often the simplest path to compliance.

You want to build without a usage meter running. Prototyping is faster when you're not watching token counts.

You have the hardware. An RTX 3070 or better is enough to run a quantized 8B model. You might already own something that works.

When It Doesn't Make Sense

You need frontier model quality. Llama 3.1 8B is good. It's not Claude Opus or GPT-4o. For complex reasoning, nuanced writing, or tasks that need the best model, call the API.

You don't want to maintain infrastructure. Local inference means keeping a machine running, managing updates, handling failures. That's real overhead.

You need massive scale. A single consumer GPU has a ceiling. vLLM on cloud instances is built for throughput.

Setting This Up

The basic path:

Install llama.cpp with CUDA support. The repo has build instructions for Linux and Windows.
Download your model in GGUF format. Hugging Face has quantized versions of most popular models.
Start the server:

./llama-server -m models/llama-3.1-8b-q4_k_m.gguf \
  --n-gpu-layers 99 \
  --ctx-size 32768 \
  --port 8080

The --n-gpu-layers 99 flag offloads everything to GPU. If it doesn't fit in VRAM, lower this number.

Point your OpenAI client at http://localhost:8080/v1.

That's the core setup. From there, you can put a proxy in front of it, add authentication, monitor it with Prometheus, or expose it behind a tunnel for remote access.

What This Looks Like as Part of an Agent

The real value of local inference isn't serving a chatbot. It's as a component inside an agent.

I use local models for cheap, fast subtasks: deciding whether a document is relevant, extracting structured data from unstructured text, generating multiple candidate outputs for a ranker to evaluate. The expensive frontier model call happens at the end, when you actually need it.

This is the pattern that makes agentic systems cost-effective at scale.

The Bottom Line

Running local LLM inference on consumer hardware is practical in 2026. The tooling has caught up. A mid-range GPU gets you a capable model at effectively zero marginal cost per call, with full data control.

It's not for every situation. But if you're building agents that make thousands of LLM calls, or handling data that can't leave your network, it's worth understanding.

Originally published at bmdpat.com. If you want help figuring out whether this architecture fits what you're building, start here.