In 2 Years Your Website Is a Data Feed, Not a Destination

By Lazar Milicevic · Published September 25, 2026 · 8 min read

A small services client of mine was getting 40 inbound emails a week. Roughly half asked for prices already listed on the website. The owner spent 2-3 hours a day retyping answers that were public. That's not a website problem. That's a "your business isn't legible to machines" problem, and it's about to get much worse.

In the next 24 months, most first-touch discovery won't be a human on your homepage. It'll be a personal agent — ChatGPT, Claude, Gemini, whatever your customer defaulted to — going out to find businesses that can respond in a structured way. Get a quote. Check availability. Book the slot. Pay the invoice. If your site is a pretty museum written for humans, it's invisible to the agent doing the actual buying.

Here's the four-layer stack I build for clients every week to replace the traditional website: a machine-readable catalog, an agent inbox, a transaction endpoint, and an observability layer. Working code, working system, real numbers.

Layer 1: The Machine-Readable Catalog

Replace your services page, pricing page, FAQ, and about page with a single structured file. Every service has a name, description, price (or price range), duration, prerequisites, and availability rule. Every FAQ has a question and a canonical answer. Every policy is a discrete field. This file is the source of truth — an agent reads it in under a second and answers customer questions with the same accuracy the owner would.

For an invoicing business I set this up for, the full catalog was one YAML file, ~300 lines, covering 42 services and 28 FAQ entries. The public website (they kept one for humans) is now generated from it. So is the agent that answers email. So is the quote generator. One source, multiple surfaces.

# catalog.yaml — the source of truth
business:
  name: "Northwind Bookkeeping"
  timezone: "America/New_York"
  currency: "USD"

services:
  - id: monthly_bookkeeping_solo
    name: "Monthly Bookkeeping — Solo Owner"
    description: "Reconciliation, categorization, monthly P&L."
    price_min: 240
    price_max: 380
    duration_hours: 3
    prerequisites: ["bank_read_access", "prior_year_tax_return"]
    availability: "rolling_start"
    tax_rule: "us_service_no_sales_tax"

  - id: catch_up_bookkeeping
    name: "Catch-Up Bookkeeping (per month)"
    price_min: 180
    price_max: 260
    duration_hours: 2
    prerequisites: ["bank_statements_pdf"]
    availability: "2_week_lead"

faqs:
  - q: "Do you work with S-corps?"
    a: "Yes. S-corp clients start at $320/mo and include payroll reconciliation."
  - q: "Can I switch mid-year?"
    a: "Yes. We handle the transition from your prior bookkeeper at no extra cost."

policies:
  refund_window_days: 14
  onboarding_sla_days: 5
  response_hours: 24

Whether it's YAML, JSON, or markdown with front-matter doesn't matter. What matters is that every field is queryable. catalog.services[monthly_bookkeeping_solo].price_max should return 380 deterministically. If you can't do that, the agent can't answer.

Layer 2: The Agent Inbox

Instead of a contact form that dumps into Gmail and sits, route inbound email through a classifier that reads, labels, and drafts a reply grounded in the catalog. For a services business handling ~300 emails/week, I set up four buckets: pricing question, booking request, existing-customer support, everything else. Pricing questions get an auto-reply with a quote pulled from the catalog. Booking requests get a proposed slot. Support gets routed to the owner with context attached. Everything else waits for human review.

The owner went from 3 hours a day on email to about 20 minutes. Not because the model is smart — because 80% of email was answerable from a structured catalog the agent could actually read.

# inbox_agent.py — simplified skeleton
import yaml, json
from anthropic import Anthropic

catalog = yaml.safe_load(open("catalog.yaml"))
client = Anthropic()

CLASSIFY_PROMPT = """Classify this email into exactly one bucket:
- pricing_question
- booking_request
- existing_customer_support
- other

Return JSON: {"bucket": "...", "confidence": 0.0-1.0, "reason": "..."}
"""

def handle(email):
    cls = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=200,
        system=CLASSIFY_PROMPT,
        messages=[{"role": "user", "content": email["body"]}],
    )
    label = json.loads(cls.content[0].text)

    if label["bucket"] == "pricing_question" and label["confidence"] > 0.8:
        draft = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=600,
            system=f"You answer pricing questions using ONLY this catalog:\n{yaml.dump(catalog)}\nIf the answer isn't in the catalog, say so.",
            messages=[{"role": "user", "content": email["body"]}],
        )
        send_draft_for_review(email, draft.content[0].text, label)
    elif label["bucket"] == "booking_request":
        propose_slot(email, label)
    elif label["bucket"] == "existing_customer_support":
        route_to_owner(email, context=lookup_customer(email["from"]))
    else:
        queue_for_human(email, label)

    log_event(email, label)  # feeds Layer 4

Two rules that keep this out of trouble:

• Grounded generation only. The reply prompt gets the catalog. It is told to refuse if the answer isn't in the catalog. No creative pricing.
• Human-approved for week one. Every draft goes to a review queue. After ~200 approvals with fewer than 3 edits each, you can flip the confidence threshold and let it auto-send.

Layer 3: The Transaction Endpoint

Most solopreneurs stop at "the AI drafts an email." That's a demo, not a system. The transaction layer is where something actually happens: a quote gets generated, an invoice is sent, a calendar slot is booked, a contract is drafted. This is the layer that closes the loop.

For one client hand-typing ~200 invoices a month, moving invoice creation onto the transaction layer took it from roughly 8 minutes per invoice to under 30 seconds. The agent resolves the customer, pulls the service from the catalog, applies the correct tax rule, generates the PDF, and sends it. The owner reviews a daily approval queue. That's it.

The endpoint should be a small set of well-typed tools the agent can call:

# tools.py
def create_quote(customer_id: str, service_id: str, notes: str) -> dict: ...
def create_invoice(customer_id: str, line_items: list[dict]) -> dict: ...
def book_slot(customer_id: str, service_id: str, iso_datetime: str) -> dict: ...
def draft_contract(customer_id: str, service_id: str) -> dict: ...

Every tool call returns an artifact ID and a status. Every artifact lands in an approval queue with an audit trail. No portal. No form. No back-and-forth. If you're on Stripe, QuickBooks, Google Calendar, Cal.com, or any invoicing tool with a real API, this layer is 2-4 days of work for a competent builder.

The pattern I use:

• Tools are idempotent. Same inputs, same artifact — no duplicate invoices when a webhook retries.
• Every artifact has a source: "agent" tag. So when something goes sideways at month-end reconciliation, you know exactly which line items came from an agent decision.
• Money actions always human-approve for the first 30 days. After that, small amounts auto-send, large ones stay in the queue.

Layer 4: Observability (The Reason Most Agent Projects Die)

This is the layer nobody talks about, and it's why most agent projects die in month two. You need to see what your agents are doing: every classification, every draft, every transaction, logged with input, output, model, confidence, and reviewer decision. Without it, the first time an agent quotes the wrong price to a real customer, you rip the whole system out. With it, you tune the catalog, tighten the prompts, and error rate drops week over week.

A minimum useful schema:

CREATE TABLE agent_events (
  id            BIGSERIAL PRIMARY KEY,
  ts            TIMESTAMPTZ DEFAULT now(),
  layer         TEXT,          -- 'inbox' | 'transaction'
  action        TEXT,          -- 'classify' | 'draft_reply' | 'create_invoice'
  input         JSONB,
  output        JSONB,
  model         TEXT,
  confidence    NUMERIC,
  human_action  TEXT,          -- 'approved' | 'edited' | 'rejected' | null
  latency_ms    INT,
  cost_usd      NUMERIC
);

Four charts I put on every client dashboard:

• Autonomy rate: % of events handled without human edit, by bucket.
• Edit distance: average change between draft and sent version. If this drifts up, the catalog is stale.
• Escalation reasons: why humans overrode the agent. This is your catalog gap list.
• Cost per handled email / per invoice. In practice, agent inbox runs $0.004–0.012 per email on Sonnet-class models. Invoices sit around $0.02–0.05 depending on how much context you feed.

Anthropic's own guidance on production agents makes this point directly — see their Building Effective Agents writeup. Skip observability and you're guessing.

The 5-Item Readiness Checklist

Score yourself honestly. One point each. Under 3 and you're not agent-ready; over 4 and you're already ahead of most SMBs.

The catalog is where I tell every client to start. It's the cheapest layer, it forces the hard conversations about what you actually sell, and it unlocks the other three. You cannot skip it. An agent inbox on top of an unstructured business is a hallucination machine.

Where bizflowai.io fits in

This four-layer stack is exactly what bizflowai.io builds for SMB clients — the catalog gets versioned in git, the inbox runs on Claude with grounded prompts pointed at that catalog, the transaction endpoint wires into whatever the client already uses (Stripe, QuickBooks, Google Calendar, Cal.com), and the observability dashboard runs on the same $18/mo mini-PC stack I use for my own agents. Nothing exotic. The point isn't the tools — it's that all four layers ship together, because shipping only two of them is how agent projects quietly fail.

What To Do This Week

You don't need a new website. You need your business to be legible. Start with Layer 1: open a file called catalog.yaml, list every service, price, and FAQ. If that file is more than an afternoon of work, that's a signal — your pricing isn't defined enough for a human either. Fix that first, and the agent layer on top becomes almost boring to build.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.