The blueprint 01Feasibility 02Business Case 03Design 04Operations 05Evaluation
Framework · Updated April 2026

A blueprint for small business AI adoption.

A phased approach that takes someone from AI curious to confident operation. Five questions, asked in order: can we, should we, how would it work, how do we run it, how do we improve it.

The questions that are hardest to answer are often the ones that matter most.
sketch your agent → start with the quick five
§ 00 Quick Start

Five questions before you build anything.

If any answer is fuzzy, that's where to start.

Most agent projects don't fail in implementation. They fail because the requirements were never honest. These five questions surface the gaps before you spend money on them.

Why it matters If you can't articulate what success looks like in a single sentence, the agent doesn't have a target. Vague directives produce vague behavior — and vague behavior is impossible to evaluate, debug, or improve.
→ covered in Phase 01 · Feasibility §1.1
Why it matters Agents have ongoing costs — compute, monitoring, your attention. If a task happens often enough that you've built routines around it (daily, or many times a week), the math usually works. Once-a-month tasks rarely do.
→ covered in Phase 02 · Business Case §2.2
Why it matters This is the question most teams skip. Without a clear definition of "correct," you can't test, measure, or trust the agent. If a wrong answer wouldn't be obvious to you, it definitely won't be obvious to the agent.
→ covered in Phase 05 · Evaluation §5.1
Why it matters Every agent needs a named owner. In a small business, that's often the person who commissioned it — write the name down anyway. Without explicit ownership, agents drift. And without a feedback loop, no one notices.
→ covered in Phase 03 · Design §3.3
Why it matters Demo success is not production success. Pick at least one measurable outcome — cost saved, hours returned, percentage handled — that you can check on a regular cadence. If you're not measuring, you're guessing.
→ covered in Phase 04 · Operations §4.1

Sketch your agent

Fill in four fields and see which parts of this blueprint matter most for your situation. Takes about a minute.

Many times daily
Daily
Weekly
Monthly or less
Easily caught & fixed
Noticeable, recoverable
Serious — financial or customer impact
Your agent brief
Where to focus in this blueprint
Want to think through this together? Book a free 15-minute conversation →
§ 01Phase 01 — Feasibility

Can we do this?

Before designing or building anything, get clear on what the agent would actually do — and whether the technical pieces exist to make it work.

1.1

Prime Directive

In one sentence, describe what success looks like when this agent is working perfectly. This sentence becomes the north star for every later decision. If you can't write it clearly, the agent isn't ready to be built.

Examples
  • Triages and resolves or routes every ticket in the support inbox without my involvement.
  • Drafts a personalized reply to each contact-form submission and flags urgent ones for me within five minutes.
  • Generates a weekly summary of new product reviews and posts the digest to our team chat.
1.2

Workflow Mapping

If you can't write step-by-step instructions for someone you just hired, the agent can't do the work either. Workflow clarity is a prerequisite, not a deliverable — and it's the single biggest predictor of whether an agent will succeed.

  • Process documentation — the entire workflow, mapped start to finish.
  • Definition of done — clear, checkable completion criteria for each step.
  • Decision branches — every conditional path. Each branch may require different tools, logic, or escalation.
  • Step count — how many distinct steps exist, and which require a human.
Field note

In my experience, workflow mapping is where most SMB agent projects stall — not because the work is hard, but because no one's ever had to describe it step-by-step before. That friction is actually useful: it surfaces the decisions you've been making on autopilot, and those are exactly the decisions the agent will need rules for.

1.3

Inputs

What information does the agent need to do its job? Map every source of data the agent will read or receive — including the things you currently keep in your head.

  • Source data — databases, file shares, email inboxes, APIs, third-party systems, your own notes.
  • Data types — structured records, PDFs, spreadsheets, free text, images, audio.
  • Decision logic — rules, decision trees, or judgments the agent must apply.
  • Context — background knowledge required: company policies, product details, your tone of voice.
1.4

Outputs

What does the agent produce, and where does the result end up?

  • Output types — updated records, generated documents, sent communications, dashboard updates, draft replies.
  • Destinations — the systems or people that receive the output.
  • Retention — how long outputs must be stored, and what compliance or audit requirements drive that.
1.5

People

AI agents change what people spend their time on. They rarely eliminate the need for people entirely. In a small business or solo practice, the same person frequently plays all of these roles — naming them anyway helps you see whether one person is being asked to do too much.

  • Current owners — who does this work today.
  • Reviewers — who will check agent output, and how often.
  • Build & test partners — the role most often underestimated. If no one has time to do it well, neither will the agent.
  • Workflow participants — everyone else who touches this process end-to-end.
1.6

Interaction Modality

How will people interact with this agent — or will it run without direct human interaction?

  • On-screen text chat
  • Voice conversation
  • Email-based interaction
  • Embedded in another application
  • Fully autonomous, headless — no human interaction during execution
1.7

Integrations

What systems does the agent need to connect to? For each, assess how readily it can be automated.

  • Systems inventory — every tool the agent reads from or writes to.
  • API availability — documented APIs, rate limits, authentication requirements.
  • Automation readiness — does the system support automated access, or is it screen-only? Tools without APIs aren't impossible to integrate, but the cost rises sharply.
§ 02Phase 02 — Business Case

Should we do this?

Feasibility tells you that you can build an agent. The business case tells you whether you should. Not every viable agent is worth building.

2.1

Value Metric

Define at least one measurable outcome tied to business impact.

Examples
  • Reduce cost per support resolution from $12 to under $5.
  • Replace six hours of weekly bookkeeping time.
  • Handle 30% of inbound emails before I read them, with no quality complaints.
  • Cut report generation time from four hours to fifteen minutes.
2.2

Volume Threshold

AI agents have ongoing costs: compute, maintenance, monitoring, and your attention. There must be enough task volume to justify those costs.

If a task happens often enough that you've built routines around it — daily, or many times a week — there's probably enough volume. Once-a-month tasks rarely justify the setup. The lower the volume, the higher the per-task value needs to be to make the math work.

2.3

Accuracy vs. Creativity

One of the most important design inputs. Some tasks require the agent to be precise and deterministic — giving the same correct answer every time. Other tasks benefit from exploration and generation. Most tasks fall somewhere in between.

Where this agent falls on the accuracy-to-creativity spectrum directly affects how it should be built. More accuracy means more structured rules, validated sources, and systematic checks. More creativity means more model freedom and heavier reliance on human review.

2.4

Cost of Error

Every agent will eventually make a mistake. The relevant questions are how easily mistakes can be detected and what happens if one is missed.

  • Detection difficulty — is the output naturally reviewed by a person, or could an error go unnoticed for days or weeks?
  • Consequence severity — financial loss, compliance violation, customer impact, reputational damage. A wrong word in a draft is recoverable. A wrong number on an invoice is not.
Field note

This is the question that most changes the architecture of an agent. High cost-of-error agents need more human-in-the-loop checkpoints, smaller autonomous steps, and more conservative autonomy levels — not because the AI is less capable, but because the asymmetry between "worked fine" and "caused a problem" is too large to ignore.

2.5

Time to Value

How quickly is this agent needed? What external deadlines exist? Timeline affects scope: a "good enough" agent in four weeks is often worth more than a perfect agent in six months.

2.6

Comparison to Alternatives

Not everything needs an AI agent. Could this be solved with a simple automation, a workflow rule, an RPA bot, or a better template? What makes intelligence and adaptability necessary here? If you can't answer this clearly, you may not need an agent.

§ 03Phase 03 — Design

How should it work?

With feasibility confirmed and the business case justified, define how the agent should behave, what guardrails it needs, and who is accountable.

3.1

Autonomy Levels

Most agents should start at Level 1 and earn their way to higher levels through demonstrated performance. Think of it like onboarding a new hire: you check the work closely at first and give more independence as they prove themselves.

3.2

Graduation Criteria

Define what evidence would justify moving the agent up a level. This turns trust into a measurable process rather than a gut feeling.

Example
  • After 30 days of >95% accuracy on reviewed outputs with zero critical errors, the agent graduates from Level 1 to Level 2 with weekly spot-check reviews.
3.3

Human-in-the-Loop Strategy

Stop-and-ask criteria. Define the specific situations where the agent must pause and get explicit approval.

Examples
  • Any financial transaction over $1,000.
  • Any external-facing communication going to a new customer.
  • When agent confidence falls below 80%.

Agent owner. Every agent needs a named owner — a person accountable for the agent's behavior, outputs, and ongoing performance. Write the name down. Without explicit ownership, agents drift.

Task horizon cutoff. How long can the agent work on a single task before it should stop? An agent stuck in a loop can burn through compute and produce compounding errors. Set a reasonable time or token budget.

3.4

Data Handling & Compliance

Lead with the practical question: what data does this touch, and who would be hurt if it leaked tomorrow?

  • Data classification — sensitivity of data the agent will touch (public, internal, confidential, restricted).
  • Personal information — customer names, emails, payment details, health information. What safeguards are required?
  • Regulatory requirements — if you're in a regulated industry (healthcare, finance, legal, education) or operate under data laws (GDPR, state privacy laws), get specific advice.
  • Credentials & permissions — give the agent the minimum access it needs. No more.
  • Audit trail — what records of the agent's actions are required for compliance, accounting, or legal purposes.
3.5

Guardrails & Safety

Beyond human review, the agent itself needs built-in safety mechanisms that work even when no one is watching.

  • Output validation — automated checks before any output goes anywhere: format, range, prohibited content, basic sanity.
  • Hallucination mitigation — for fact-dependent agents, ground outputs in retrieved source material and require citations.
  • Scope boundaries — what the agent should explicitly refuse to do, even if asked.
3.6

Agent Configuration

Technical identity and behavior settings.

  • Agent name and role description
  • Expertise sources — prompt engineering, knowledge bases, retrieval-augmented generation
  • Trigger events — manual invocation, scheduled, event-driven
  • Expected run length — seconds, minutes, hours
  • Tools and APIs the agent can access
3.7

Fallback & Recovery

What happens when the agent is unavailable or underperforming? Every production agent needs a fallback plan.

  • Fallback plan — manual reversion, simplified backup mode, or graceful pause.
  • Communication plan — who gets notified, and how quickly, when things break.
  • Recovery threshold — the maximum acceptable downtime before business impact becomes unacceptable.
§ 04Phase 04 — Operations

How do we run it?

A deployed agent is not a finished product. It requires ongoing monitoring, cost management, and maintenance.

4.1

Performance Metrics

  • Goal completion rate — percentage of tasks completed successfully without human intervention. Set a target (e.g., greater than 85%).
  • Latency budget — maximum acceptable response time. Varies enormously by use case: under two seconds for real-time chat, under a minute for complex analysis, minutes or hours for batch.
  • Domain-specific quality metric — the single measure that matters most for this use case (accuracy, compliance rate, customer satisfaction, resolution rate).
4.2

Observability & Cost Controls

  • Cost controls — token and compute limits per user and per day. Per-task cost monitoring. Budget alerts and hard caps. Agents without spending limits become expensive surprises.
  • Logging — activity logs sufficient to diagnose problems and audit decisions.
  • Damage control — self-detection of failure states and automatic stopping to prevent wasted spend and compounding errors.
Field note

For SMBs, cost controls are often the most underestimated requirement. A single misbehaving agent running overnight can generate a surprising bill. Set hard daily caps from day one — even if they feel conservative. You can always raise them after you understand your actual usage patterns.

4.3

Maintenance & Lifecycle

AI agents are not "set and forget." Data changes, models are updated, and business processes evolve.

  • Knowledge refresh — how often knowledge sources need updating. Stale knowledge directly degrades accuracy.
  • Model updates — when the underlying AI model changes, what regression testing is required.
  • Retirement criteria — conditions under which the agent is shut down (process changes, cost exceeds value, replaced by a better approach).
§ 05Phase 05 — Evaluation

How do we test and improve?

Evaluation starts during development and continues throughout the agent's life. It's the difference between an agent that works in a demo and one that works in production.

5.1

Golden Test Set

A collection of real-world examples with verified correct answers. This is your objective measurement of whether the agent does its job correctly.

  • Minimum size — start with 15–20 examples you can hand-grade. Build toward 50 as the agent matures. The first 20 catch most of what matters.
  • Composition — typical cases, edge cases, tricky scenarios, and examples that should be rejected or escalated.
  • Ground truth — each example has a verified correct output. Without ground truth, you don't have a test set; you have a wishlist.
  • Maintenance — update when business rules change or new edge cases surface.
5.2

Testing Strategy

  • Edge case testing — unusual or unexpected inputs (missing data, garbled text, out-of-scope requests).
  • Adversarial testing — deliberate attempts to misuse the agent or cause unintended behavior.
  • Regression testing — after every update, re-run the golden set to confirm nothing broke.
  • Drift monitoring — ongoing tracking of output quality over time. The world changes around the agent; performance can degrade even when the agent itself hasn't changed.
§ 06Closing

The hardest part of building AI agents isn't the technology. It's the requirements.

The fields in this framework that are most difficult to fill in are almost always the ones that matter most. If you can't articulate the agent's prime directive, if the workflow hasn't been mapped, if no one can define what a correct output looks like — those aren't reasons to skip ahead. They're reasons to pause and do the foundational work.

Agents that succeed in production share a common trait: the people who built them invested time to understand the work before trying to automate it. This framework is designed to structure that investment.

Use it iteratively. Revisit sections as you learn. Whether you're a solo operator or a growing team, the best agents come from the same thing — honest answers to hard questions, asked early.

book a conversation → see the work