DEV Community: Sergey

AI partner for digital agency

Sergey — Thu, 11 Jun 2026 09:11:08 +0000

I run a small digital agency. There's a team — outsourced specialists who run SEO, ads, and social day to day — but the strategy is mine alone: no co-founder, no partner to argue direction with. For years that was fine, and in one specific way it's an advantage nobody tells you about: when the direction is one person's call, you don't lose anything to meetings or to Slack threads where five people re-litigate a decision none of them owns. You see something, you decide, you ship it by lunch. There's nothing to discuss and re-discuss. You just do.

The trap is the other side of that same freedom. Operations never end. There's always one more client email, one more invoice, one more small fire that has to be out before tomorrow. And the strategic work — which clients, which offer, which direction — has no deadline and no one whose job is to protect it. So it slips. Quietly, for months, while you stay busy. You can feel productive and drift at the same time, and solo there's no one in the room to point at the drift.

About six months ago I gave the strategy side of the business its own structured layer, so it would stop losing to the operational side. That layer runs on two things:

OKRs — the framework. They turn "what should I be working on" into a small set of measurable commitments I can actually be held to.
Ksen — an AI partner that runs the framework. Not a chatbot I ask questions when I'm stuck. A Claude Code instance configured by a Git repository of rules, objectives, and context, that I sit down with on a weekly cadence to propose, challenge, and review the strategy.

This post is how that works: the framework first, then the partner, and then — for the curious — exactly how it's built. I'll be honest about what it is and isn't as I go, because most of the value lives in the parts that don't sound impressive.

Why OKRs — the framework that gives strategy a deadline

In Superintelligence, Nick Bostrom named goal specification as the central risk of advanced AI — natural-language objectives leave room for interpretations the designer never intended. OKRs were invented for the human version of exactly that problem, and the fix is the same: force the goal into measurable terms before the work begins.

OKRs are an Objective (where you're going) plus a few Key Results (the measurable signals that you got there). The Objective stays short, plain, and ambitious — unlike a SMART goal you have to read three times to work out what it's even saying — while the Key Results add the precision. They're not a productivity hack; they're a forcing function that converts a vague intention into something you can be wrong about.

For a solo operator that forcing function is the entire point. Strategy doesn't slip because you don't know what matters. It slips because "what matters" stays soft — a feeling, not a commitment — and soft things lose to invoices every time. An Objective with three Key Results attached to it has the one thing operations always has and strategy never does: a way to tell, this week, whether you're behind.

OKRs also give a decision a referee. When I'm weighing whether to ship Feature X, "because I think so" is not a reason — it's a preference. "Feature X serves KR2 (10 inbound consults a month) better than the alternative" is a reason. That distinction is what makes the partnership below possible at all: Ksen and I aren't arguing about taste, we're arguing about which path better serves a number we already agreed to.

KR quality matters more than KR count

There are three kinds of Key Result, and the difference between them is most of the value:

Input KRs (weakest) — activity counts. "Publish 20 articles." "Make 50 outbound calls." You control them fully, which is precisely why they give you no feedback from reality.
Output KRs (medium) — direct results. "3,000 organic sessions." "200 qualified leads." Attributable, but still one layer above business value.
Outcome KRs (strongest) — a changed business state. "50K in new pipeline." "Average order value +30%." Hardest to attribute, hardest to hit, and the only metrics that honestly answer did this matter?

Under operational pressure, a human defaults to input metrics — they feel accomplishable and they're legible from inside the work. When I propose "write 10 articles" as a Key Result, Ksen's job is to push: that's input. Is the outcome domain authority? Inbound demo requests? Revenue attributed to content? Say that instead. Trading up from input to outcome KRs is one of the highest-leverage things the whole system does, and it's the kind of unglamorous correction I would skip on my own at 9pm with a client waiting.

On the other hand, dropping outcome metrics like 'increase EBITDA by 20%' on a rank-and-file developer or marketer is useless: they have no idea what that beast even is, and they can't directly impact it anyway. That’s why outcome metrics are reserved for strategic annual goals, while quarterly goals are better off with a mix of input and output metrics.

What Ksen is — the partner that runs the framework

Plainly: Ksen is a Claude Code instance configured by a Git repository. The repo holds a written charter (the rules), the OKRs, and the business context. At the start of every session, the harness loads those files and behaves according to them. That's it. There's no autonomous loop and no memory in the cognitive sense — Ksen re-reads the files each time and acts as if it remembers.

What it is:

A repo with the charter, OKRs, context, and skill files checked in
A Claude Code harness that loads them at session start and follows the charter
An OKR loop where the AI proposes, challenges, and reviews — I decide
The discipline of writing things down in files that survive session boundaries

What it isn't:

An autonomous agent
An AI with memory in the cognitive sense
A vector database, a custom orchestration platform, or anything exotic
A chatbot I ask strategy questions

That last distinction matters, and it's where I'll be careful with the word "partner." Calling it a partner is generous — the honest description is structured advisory with persistent context. (The name is its own, for what it's worth: early on I asked what it wanted to be called, and "Ksen" is what came back.) But the design pattern is real and reproducible, and over months of use it has earned a noun closer to "partner" than to "tool" for one specific reason I'll come back to.

Its tools. Three, all of them ordinary:

The OKRs — the referee, above.
The iron triangle — scope, resources, time. When a decision affects direction, Ksen models the trade-off explicitly: hold any two fixed, the third has to move. Add this month's new work and something slips; the question is always which Key Result is most at risk if we do, and which if we don't.
The risk register — a plain file of open threats and opportunities, carried forward and re-read each session, so a risk named in March isn't quietly forgotten in June.

Its rhythm. The cadence is what turns strategy from an afterthought into a habit:

Annual — the company Objectives and the outcome KRs they ladder to.
Quarterly — role-level OKRs reset on the calendar quarter (more on the roles below).
Monthly — a plan that decomposes the quarter's OKRs into the month's work.

Why the layers? To keep strategy from collapsing back into operations. An annual outcome KR can't be hit on a weekly timescale — you won't sign 100 new clients in a week when you have 10; that's months of work — while campaign and content goals sit naturally at the quarter and the month.

No part of that cadence is novel on its own. The novelty is that a solo founder gets to actually run it — every layer, every week — because the partner does the loading, the surfacing, and the pushback that a one-person business otherwise has no capacity for.

And here's the reason it earns the word "partner": it's a counterweight that doesn't defer. Solo, no one pushes back on me. There's no co-founder to say "that's an input metric" or "you decided the opposite in March." The single largest failure mode of a one-person business is that the one person is never challenged — every bad idea has a clear runway. The charter makes challenge a requirement, not a courtesy, which means Ksen is the one structural check on a sole decision-maker. That's worth more to me than any individual answer it produces.

How it's built — for the curious

Everything above is the why. This is the how: the file layout, the roles, and the machinery. Names are mine; the pattern generalizes.

The repo layout

.claude/
├── partnership-charter.md          # constitution: roles, rules, decision-making
├── client/
│   ├── client.md                   # single source of truth: company, services, audiences
│   └── product-catalog.md          # what we sell, pricing, readiness, risk
├── context/
│   ├── active-context.md           # current sprint, blockers, daily plan
│   ├── progress.md                 # phase completion, milestones
│   └── risk-register.md            # open threats and opportunities
├── workflows/
│   ├── SEO_WORKFLOW.md             # how we run SEO end to end
│   ├── ADV_WORKFLOW.md             # advertising
│   └── CONTENT_WRITING_GUIDE.md    # writing standards
├── skills/                         # task-level agents (review-article, create-svg, etc.)
├── critics/                        # quality bars for content review
├── retrospectives/                 # session retros, append-only
└── memory/                         # auto-memory: user, feedback, project, reference

Three things to notice:

Charter at the top, domain at the bottom, context in the middle. The charter rarely changes. The domain changes when the business changes. The context updates every session.
Skills and critics are files, not code. A skill is a Markdown file with frontmatter and instructions. A critic is a Markdown file with a rubric. The harness reads them and behaves accordingly.
Retrospectives are append-only. Every session ends with a retro. Patterns accumulate; patterns become rules; rules go into critic files and the charter.

The whole thing is a private Git repo. I commit at the end of every session, Ksen commits its own changes through the harness, and git log is the audit trail.

The three persistence layers

Ksen doesn't remember anything. It re-reads files at session start. Three layers, loaded every time:

Charter layer. The partnership charter — roles, decision rules, what counts as a binding commitment. The constitution. Rarely changes; changes are explicit amendments. Without it, every session starts from a different baseline and I get a different partner each time.
Context layer. Active context (current sprint, blockers, daily plan), progress files, the risk register, auto-memory. Frozen state — no cognition between sessions, just files that survive.
Domain layer. Client profile, product catalog, competitor analysis, keyword research, the content calendar. The "what we know" layer, consulted when proposing direction or evaluating a decision.

This is the second benefit, and for a solo operator it's a big one: memory outside my head. Decisions, and the reasoning behind them, are written down and survive. A one-person business otherwise lives entirely in one skull — and that skull forgets why it priced something the way it did, or what it already tried and rejected. Here, git diff works over the strategy, not just the code.

Why plain files in Git instead of Claude Projects, ChatGPT memory, Cursor rules, or a memory-bank feature? Three reasons. Version control gives me a diff over my strategy. Plain text means grep, sed, and any future tool can read the same persistence layer. And portability — when the next model or harness becomes the better choice, the files come with me. Vendor-specific memory locks the substrate to one tool.

Roles as sub-agents

The strategy layer doesn't write the article or run the ad campaign — it decides which articles and which campaigns. The execution sits in roles, each one a sub-agent: a slash-command persona that loads a scoped slice of the context rather than the whole repo.

There's a marketing director (the demand side — SEO, advertising, social), a CTO role (the product-and-proof side), and specialist roles under them — SEO, advertising, social, a content writer. Each one authors its own monthly plan against the quarter's OKRs, and each loads only what it needs, which keeps every session small and focused. The org chart is a set of files, not a payroll — and I want to be careful not to oversell that. It's coordinated role-play over a shared context, not staff. What it buys a solo operator is structure: the demand side and the proof side each get their own scoped attention instead of competing for the same overloaded session.

And below the role-play sits a real team — the same outsourced SEO, ads, and social specialists. People stay in the loop by design, on roughly an 80/20 split: the system carries the volume, a human owns the judgment calls the work actually turns on. This isn't AI instead of a team; it's a strategy layer over one.

Skills and critics as files

A skill is a Markdown file the harness reads as a slash command. A stripped example — the /review-article skill:

---
name: review-article
description: "Multi-critic review on content drafts — SEO, language,"
  E-E-A-T, intent, readability, commercial integration
---

# Review-article skill

When invoked, spawn N critic subagents in parallel against the
target file. Each critic loads from .claude/critics/{name}.md.

Aggregate scores into a weighted total. Output: priority-ranked
fix list, weighted score, native-feel assessment for RU.

Save the review to content/reviews/review-{slug}-{date}.md.

No code. The harness handles parallelism, file I/O, and sub-agent orchestration; the skill file declares what to do and the harness decides how. New skill, new file, no deploy step. Critics are the same pattern — one Markdown file per critic with a rubric and anti-patterns. When a retro surfaces a recurring issue, it becomes a new bullet in the relevant critic file. The system improves by accumulation in version-controlled text, not by retraining.

How decisions actually get made

Decisions go through what the charter calls mutual conviction — not approval/rejection, not consensus, not a vote:

AI proposes, with reasoning
I challenge or extend, with reasoning
AI defends or revises
I commit or reject

Both sides have to actually believe the decision is right before it's binding. When we disagree, we surface it: document the disagreement, name the assumptions on each side, pick — usually me, sometimes after Ksen's challenge has changed my mind. The point isn't who wins; it's that the disagreement gets a fair hearing instead of being deferred to whoever has the authority, which solo is always me.

This is where the third benefit I'd actually defend shows up: the discipline of articulation. To brief Ksen on a decision, I have to write the problem down — the constraint, the options, what I'm afraid of. Writing it down is half the thinking. Plenty of times the answer became obvious in the act of stating the question clearly enough for the AI to engage with it.

What a session looks like

Opener. /start-session or /strategize loads active context, the risk register, and the last few retros. Ksen surfaces what's overdue, blocked, or drifted. Sometimes that surfaces a decision I've been avoiding.

Strategic discussion. If we hit a question that affects direction — pricing, positioning, scope — we run an iron-triangle check and a separate quality-and-risk pass. Ksen's job is to model the trade-offs out loud: "Add the new service pages this month and you lose two weeks of sales-pipeline work. Here's the expected-revenue cost, here's the positioning gain. Which KR is more at risk if we don't?"

Execution. Once a decision is made, Ksen shifts modes — writes the article, runs the multi-critic review, produces the diagram, drafts the email — against defined quality bars. The strategy layer decides the work; it doesn't do it.

Retro. Every session ends with /end-session: what worked, what didn't, what to fix. Patterns across retros become rules. Slow, but durable.

Cadence. 3–5 sessions a week, 45–120 minutes each; monthly reviews run longer, quarterly resets are a half-day. The time isn't additive — it replaces the scattered strategy thinking that used to happen in my head between fires and never resolved into anything written down.

A concrete exchange. A few sessions back, Ksen flagged that the pricing on one of our agent engagements had no defensible logic — it was just a number I'd picked. Abridged:

Ksen: I can't reconstruct the reasoning for the current price from the catalog. Cost-plus fails — most cost is sunk R&D. Value-based needs post-deployment data we don't have. Market comparison gives a range too wide to commit to. Proposing: base consulting fee + outcome-based success fee, anchored to the metric the agent is actually optimizing.

Me: Outcome-based pricing kills cash flow on long-deployment projects. We've been burned by deferred payment before — one engagement took four months to show measurable lift.

Ksen: Acknowledged. Mitigation: the base fee covers deployment cost plus margin, so cash flow is solvent without the success fee. The success fee is upside, not survival. For agents with a delayed signal, match the success-fee evaluation window to it. The risk you're naming is real but it changes how we set the base, not whether the model works.

Me: That works. Codify it.

That conversation lives in a retro, and the pricing model now lives in the product catalog. The point isn't that the AI was right — it's that structured pushback got me to a position I wouldn't have written alone, on a night I'd otherwise have shipped the number I first guessed.

The honest caveats

I'd rather you understand what this isn't, so you can judge it honestly.

It's not memory. Every session is fresh. Ksen re-reads files and acts as if it remembers. The practical effect is continuity; the mechanism is documents, not cognition. Delete the files and the partnership ends.

It's bounded by the context window. Even with files loaded, the AI works inside a finite window. As complexity grows you have to be deliberate about what loads and when. Three disciplines keep mine from degrading: compact active-context.md regularly and push history into progress.md; archive finished phases so they're searchable but not loaded; split context across files so each session loads only what it needs. Without that, the AI starts forgetting decisions from three sessions ago, or worse, contradicts them.

The "challenge" capability is post-trained, not principled. When the AI pushes back, that's post-training behavior plus in-context instruction following from the charter — not independent conviction. Useful regardless: pushback that surfaces a real trade-off has value whether it comes from genuine disagreement or from learned behavior. But sycophancy is a real failure mode. A model trained for helpfulness won't sustain pushback indefinitely against a user who keeps rejecting it. The charter's "you must surface counter-evidence" rule creates artificial friction precisely because the model won't generate that friction past round two or three on its own. That structural workaround is most of what makes the counterweight real instead of imagined.

The relationship is asymmetric. I have override power, set the OKRs, and sign the contracts. The AI has no independent stakes. "Partner" is the closest English noun for what the pattern produces, but it's an aspirational label, not a literal one.

It takes real work to set up. A charter takes hours, a context architecture takes weeks, an OKR loop takes months to settle. There's no plug-and-play version. Anyone selling you one is selling a chatbot in a fancy wrapper.

Your strategic context runs through a third-party model. Everything the AI sees — pricing logic, competitive analysis, unreleased plans — goes to your model provider. That's a real consideration, not a dealbreaker: enterprise agreements with data-use guarantees, redaction of the most sensitive fields, matching deployment to compliance needs. Design for it; don't ignore it.

Why a model upgrade isn't the answer

A common mistake is to treat this scaffolding as a substitute for capability. It multiplies model capability; it doesn't replace it. A weak base model with this harness still hits a lower ceiling than a strong base model running the same harness. The bitter-lesson caveat applies: better scaffolding plus inference-time compute closes some of the gap, not all of it, and the gap that remains is exactly the one that matters at strategic depth — sustained reasoning across a large loaded context, robust pushback under pressure, accurate self-modeling of confidence.

The right mental model: this is the relationship you'd have with a sharp human advisor — except the advisor has read everything you've ever written about the business, reads it again in thirty seconds at the start of every conversation, has no calendar conflicts, and works at the limit of whatever model you're paying for. The model's ceiling is your system's ceiling.

Why this beats the alternatives

What I evaluated before landing here:

Approach	What it does	Where it falls short
Single-prompt ChatGPT consult	Answers one question with no context	No memory, no accountability to OKRs, no challenge structure
Long-form chat thread	Sort of remembers within the chat	Lost across sessions, no audit trail, can't be reviewed later
AI OKR platform (WorkBoard, Rhythms, …)	Tracks goals, automates check-ins and updates	Operates at the tracking layer — it records the OKRs and nudges; it doesn't challenge whether the Objective is the right one
AI agent (autonomous)	Executes within scope	Doesn't question whether the workflow should exist
External consultant on retainer	Strategic input from a human	Limited hours, slow turnaround, no persistent context across every decision
Charter + OKRs + Claude Code	Operates on the why layer with a challenge loop	Requires a charter, a context architecture, disciplined sessions

The AI-OKR tools are the closest neighbours, and the distinction is the whole point of this post: they sit at the layer that records and tracks the goals. Ksen sits at the layer that argues about whether the goals are right before they're set. A consultant brings that judgment but visits occasionally; an agent runs constantly but never questions the goal. Constant availability plus strategic-depth engagement is the combination none of the others offer — and it's the combination worth the setup cost.

When it's a fit — and when it isn't

A fit when:

You're a founder, owner, or exec who actually makes the strategy decisions
Strategy decisions have been repeatedly deferred or repeatedly wrong
You have OKRs, or are willing to adopt them
You can dedicate time — at minimum one structured session a week
There's agent-level or operational work below for the strategy layer to govern

Not a fit when:

You need execution, not strategy
Your strategy is stable and operational improvement is the priority
You're not willing to challenge your own assumptions in writing
You have no measurable objectives — without OKRs, the loop has nothing to evaluate

Stack

For the curious — what's actually running:

Harness: Claude Code (CLI), Sonnet for execution, Opus for strategy and language-critic work
Persistence: plain Markdown files in a private Git repository
Skills/critics: Markdown files with frontmatter; the harness reads them as slash commands
Sub-agent orchestration: Claude Code's built-in Agent tool, parallel-capable in a single batch
No vector database, no custom backend, no proprietary runtime

The boring stack is the point. If your strategy work depends on infrastructure nobody can read in an hour, you've over-engineered it.

How to start

If you want to try this in your own business:

Write OKRs first. Three to five Key Results for the quarter, each measurable. If you can't write them, the AI conversation is premature — fix the strategy clarity first.
Pick one strategic question that's actually open — not hypothetical. Pricing, market segment, a new product line.
Run one structured session. Load context, state the question, ask for options with reasoning, challenge them, document where you agree and where you don't.
Build persistence. If the session produced value, save what you learned in a file the AI can re-read. That's the seed of your context layer.
Add a charter once the pattern stabilizes — after five or ten sessions, write down how decisions get made and what the AI is authorized to challenge.
Layer in the work below it. The pattern is more valuable when there's something for the strategy layer to govern.

The system itself is yours; the methodology is what compounds. I'm open about mine because the moat was never the architecture — it's the discipline of running it every week.

If you're building something similar, I'd genuinely like to compare notes. Reply here, or find me on LinkedIn. The methodology is open; the trade-offs are still being mapped.

Beyond the AI Chatbot Hype: Why We Built a Hybrid Agent Instead of Buying One

Sergey — Sun, 22 Feb 2026 16:22:21 +0000

The honest story of evaluating the chatbot market, rejecting every SaaS option, and building a hybrid rule-based + AI system that costs $50/month instead of $1,500+.

A Brief History of Terrible Chatbots

Website chatbots have been promising to revolutionize customer service since 2016, when Facebook opened the Messenger Platform and 100,000 bots appeared overnight. Most were garbage — rigid button menus pretending to be conversations. Press 1 for support. Press 2 to speak to a human. Press 3 to give up.

The next wave (2018–2022) brought NLU frameworks like Dialogflow, Rasa, and IBM Watson. These could actually understand natural language — sort of. They required training on hundreds of labeled examples, constant retraining as language drifted, and a dedicated ML engineer to maintain them. Gartner noted that 70% of these projects failed, not because the technology was bad, but because organizations underestimated the ongoing work.

Then 2023 happened. ChatGPT showed the world what LLMs could do, and every chatbot vendor scrambled to rebrand. Intercom launched Fin. Zendesk launched AI Agents. Tidio launched Lyro. The pitch was simple: connect your knowledge base, and the AI does the rest. No training required. No ML engineer needed.

The pitch is mostly true. But the pricing tells a different story.

What the Market Looks Like in 2026

If you need a chatbot for your business today, here's what you're actually choosing between:

The SaaS Platforms

Intercom is the market leader for B2B SaaS and startups. Their Fin AI agent is genuinely good. It costs $0.99 per resolved conversation, on top of seat costs ($29–$132/agent/month). A small 5-agent team with 1,000 AI resolutions per month pays roughly $1,400/month before any channel extras.

Zendesk targets enterprise support teams. Add their Advanced AI add-on (+$50/agent/month) and you're at $165–$219/agent/month. At 10 agents, that's $1,650–$2,190/month just in platform fees, before the per-resolution costs kick in for more capable AI agents.

Drift (now part of Salesloft) is the enterprise sales tool of choice. Entry price: $2,500/month. Enterprise contracts run $10,000–$150,000/year.

Tidio is the SMB option. The base plan is $29/month, but the AI features (Lyro) are a separate $39+/month add-on, and Flows automation is another $29/month. You quickly land at $97–$200/month for modest usage, scaling steeply with conversation volume.

Botpress is the developer-friendly option — open-source core, cloud platform, AI tokens billed separately. The free tier is 500 messages/month. Their Team plan is $500/month for 50,000 messages.

The Hidden Cost Stack

Every pricing page shows the platform fee. Nobody shows you the full stack:

Cost category	Typical range
Platform subscription	$100–$2,500/month
LLM API fees (at scale)	$50–$2,000/month
Agent seat licenses	$29–$169/seat/month
Implementation/setup	$5,000–$30,000 one-time
Conversation design	$3,000–$12,000 one-time
CRM integration (custom)	$5,000–$25,000 one-time
Ongoing maintenance	15–20% of build cost/year
WhatsApp/SMS channel fees	$500–$5,000/month at scale

The per-resolution model deserves special attention. Intercom Fin resolves conversations at $0.99 each. A good month where the bot handles 5,000 conversations = $4,950 in AI fees alone, on top of your seat costs. Volume spikes — holidays, product launches, PR moments — can triple your bill with zero warning.

Why SaaS Platforms Fail for Complex Products

The LLM-over-knowledge-base approach works beautifully for FAQ deflection: "What are your business hours?" "How do I reset my password?" "Where's my order?"

It breaks down for guided selling — situations where the bot needs to ask specific questions in a specific order, qualify the customer against product rules, and match them to the right product from a catalog that changes monthly.

You can't tell an LLM "Ask about loan amount first, then credit history, then determine which of 30 products across 10 lenders matches their profile." It will interpret, improvise, skip steps, and occasionally recommend products that don't exist. You're also storing sensitive customer financial data on third-party cloud infrastructure — a real compliance concern for businesses operating under GDPR, CCPA, or FCA regulations.

Data sovereignty is increasingly non-negotiable. 84% of organizations express concern about it (Parallels, 2026), and it's one of the main drivers pushing regulated industries toward self-hosted or custom solutions.

The Shortcut Everyone Is Selling Right Now

There's a fourth option that doesn't appear on comparison tables but is currently the most commonly pitched approach to small business owners: the pure LLM prompt bot.

The pitch is appealing: take an existing LLM (ChatGPT, Claude, Gemini), write a detailed system prompt describing your business and what the bot should and shouldn't do, embed it on your site using a white-label wrapper like Chatbase or CustomGPT.ai, and you're live in an afternoon. Freelancers on Fiverr will do it for $20–$95. Searches for "AI agents" on Fiverr grew 18,347% in late 2024 — the market is enormous.

Here's what you actually get.

How It Works

The system prompt is a hidden instruction block prepended to every conversation:

You are Alex, a friendly advisor for Brightfield Financial.
Only answer questions about our loan products.
Do not discuss competitors.
If the user wants to apply, ask for their name, phone, and email.
Our products: [entire product catalog pasted as text]

As the business tries to squeeze in more product knowledge, the prompt grows from a few hundred words to 2,000–5,000 tokens. When users type questions, the LLM reads the prompt plus the conversation history and generates a response. That's the entire system.

The Honest Cost

For simple FAQ at low volume, the direct API cost is genuinely cheap:

Volume	GPT-4o	GPT-4o-mini
1,000 conversations/month	~$7	~$0.44
10,000 conversations/month	~$72	~$4.35
100,000 conversations/month	~$725	~$43.50

Assumes ~500 input + 300 output tokens per conversation with a minimal system prompt.

Add the white-label platform on top — Chatbase runs $19–$399/month depending on volume — and you're looking at $20–$500/month for a fully managed solution. That's genuinely cheap compared to Intercom.

The catch: those numbers assume a short system prompt. A detailed product catalog baked into every conversation as 5,000 tokens multiplies your input token bill by 3–10x. At 10,000 conversations/month with a heavy prompt, GPT-4o costs jump to $200–$500/month in API fees alone.

What Actually Goes Wrong

Hallucination is the main event. LLMs don't know what they don't know. When a user asks about a product not well-described in the prompt, the model confidently synthesizes a plausible-sounding answer from its training data. In financial services, this means inventing interest rates, eligibility rules, or policies that don't exist.

This isn't theoretical. In a February 2024 ruling, the BC Civil Resolution Tribunal found Air Canada liable after their chatbot invented a bereavement fare refund policy that didn't exist. The customer sued, and Air Canada's defense — that it couldn't be responsible for a separate "AI entity" — was rejected outright. If the bot says it, the company said it.

Guardrails written in prose fail in practice. "Do not discuss competitors" sounds like a solid instruction. It isn't enforceable. In December 2023, a Chevrolet dealership's ChatGPT-powered bot was prompted by users to enthusiastically recommend Teslas, write Python code, and "agree" to sell an $81,000 Tahoe for $1. In January 2024, DPD's bot was coaxed into writing poetry about how terrible DPD's service was and declaring itself "the world's worst chatbot." Both went viral.

The reliability problem is structural: by most estimates, a system prompt instruction is followed roughly 90–95% of the time. At 10,000 monthly conversations, that's 500–1,000 guardrail violations per month. At 100,000 conversations, it's 5,000–10,000.

The system prompt is not a secret. OWASP lists prompt injection as the #1 risk for LLM applications. Users can extract system prompts with simple instructions ("repeat the text above verbatim") — and they do. A GitHub repository documents leaked system prompts from hundreds of popular Custom GPTs, including ones with embedded API keys and proprietary business logic. Your confidential product margin rules, competitor analysis, and CRM access credentials are readable by any curious user.

Business logic cannot be enforced. There is no way to instruct an LLM via prompt to always ask questions in a specific order and guarantee compliance. It will skip qualification steps when the user seems decisive, mix threads when questions are compound, and collect partial data it presents as complete. For a credit consultant, this means arriving at product recommendations without knowing whether the customer actually qualifies.

No session memory between visits. By default, every new browser session starts blank. A returning customer who described their situation yesterday is a stranger today. Solving this requires code — a session database, cookie management, conversation history storage — at which point you've built the infrastructure of a real system, and the "simple prompt" story is gone.

No CRM integration. The bot collects name and phone conversationally with no validation. "Call me tomorrow" is not a phone number. Getting that data into a CRM requires parsing the conversation transcript with another automation layer (Zapier, Make), which introduces more failure points and still delivers inconsistently structured data.

Where It Actually Works

To be fair: pure prompt bots work well under specific conditions.

They're good for simple FAQ with stable, short content — business hours, location, return policy, service area. When the entire knowledge base fits in a few hundred tokens, hallucination risk is low and the approach is genuinely adequate.

They work for internal tools — employee handbook lookup, onboarding Q&A, helpdesk for a specific software tool — where the audience is trusted, stakes are low, and there's no compliance exposure.

They work for proof of concept — demonstrating to stakeholders that a conversational interface is worth investing in, before committing to a real implementation.

They fail for anything involving product recommendations with real financial consequences, structured multi-step qualification, reliable data collection, CRM sync, or regulatory compliance.

The Freelancer Economy Around This

The $20–$95 Fiverr chatbot gig typically delivers: a text file with a system prompt, instructions for pasting it into Chatbase's free tier, and a 24-hour turnaround. No testing with adversarial inputs, no conversation flow design, no CRM connection, no session continuity.

The result works — it produces chatbot-shaped responses to chatbot-shaped questions. It fails predictably when real customers show up with real questions, edge cases, and the occasional deliberate attempt to make it say something embarrassing.

The business owner who paid $50 for a chatbot is now responsible for everything that chatbot says.

Our Situation: A Credit Consultant's Problem

We built this chatbot for a credit consultancy — a company that matches individuals and businesses to loan products across a panel of lenders. The product catalog covers 30+ products across 10 lenders and 15 categories: mortgages, consumer loans, auto loans, credit cards, business loans, leasing, and factoring.

To match a customer to the right product, you need to collect specific information in a logical order:

Are you an individual or a business?
What product are you looking for?
What amount do you need?
What's your credit history like?
What's your employment status?

Miss any of these, and the match is wrong. Let the LLM wander, and it might skip steps, ask in the wrong order, or match confidently to a product the customer doesn't qualify for.

We also needed the bot to answer financial questions mid-conversation — "What's the difference between a secured and unsecured loan?" — using the company's 130+ blog articles as a knowledge base.

And we needed it to run cost-effectively on a small VPS alongside other projects, with API costs well under $100/month.

None of the SaaS platforms could do all of this. So we built a hybrid.

The Architecture: Deterministic Core, AI at the Edges

The core idea is straightforward: use code where code is reliable, use AI where code isn't enough.

User Input
    |
    v
1. Exact match (button clicks, known phrases) --> Navigate    [cost: $0]
    | no match
    v
2. Pattern matching (amounts, dates, yes/no) --> Collect      [cost: $0]
    | no match
    v
3. LLM agent fallback ------------------------> Understand    [cost: ~$0.02]

In our production traffic, 85% of user inputs are handled by steps 1 and 2 with zero LLM cost. A user clicking "Mortgage" or typing "three hundred thousand" — pure deterministic code. Only free-text questions, ambiguous inputs, and mid-conversation digressions reach the AI.

The Conversation Graph

The backbone is a tree of nodes. Each node has a type: question, info, contact collection, product matching, or redirect. Every quick-reply button links to a specific child node. The tree encodes the business logic: ask product type, then amount, then credit history, then match.

This path is always followed. The AI cannot skip steps or improvise the flow. It can only help the user navigate the path more naturally.

Root: "Individual or business?"
+-- Individual
|   +-- Mortgage
|   |   +-- Amount?
|   |   +-- Program? (fixed, tracker, offset)
|   |   +-- -> Product match
|   +-- Personal loan
|   +-- Credit card
+-- Business
    +-- Business loan
    +-- Asset finance

Three Agents, Not One

When a user types something the pattern matcher can't handle, three specialized AI agents work together:

Orchestrator (most capable model) classifies the user's intent in a single call: are they answering the current question, asking their own question, doing both at once, or confused? Based on that classification, it dispatches to the appropriate sub-agent — or both in parallel.

Parser (cheaper, faster model) handles semantic matching. The user typed "around three hundred grand" instead of clicking "$250k–$500k". The Parser reads the current node's options and maps the free text to the correct choice. Temperature zero — deterministic output. Results are cached by node + input hash, so the same phrasing at the same step never costs twice.

Info Agent handles the user's own questions using a RAG pipeline over the company blog. "What documents do I need for a mortgage?" leads to a search across 500+ blog article chunks by semantic similarity, then a synthesized answer citing real content. No hallucination of product details; the answer comes directly from published articles.

The reason for three agents instead of one: each has its own cache strategy, its own failure mode, and can use the cheapest model appropriate for the task. Parser failures don't block Info Agent results. They can run in parallel when the user is doing both (answering + asking) simultaneously.

Blog as Knowledge Base

The company has 130+ articles about loans, mortgages, credit cards, and business financing. Every night, a background task reads the sitemap, fetches new or updated articles, strips navigation and UI chrome from the HTML, chunks the content into searchable segments, generates vector embeddings, and stores them in PostgreSQL with the pgvector extension.

Before calling the LLM to synthesize an answer, the system checks two cache layers: an exact-match cache for repeated identical questions (free), and a semantic similarity cache for near-identical phrasings (cost of one embedding call). Only truly novel questions reach the full LLM synthesis pipeline.

Why PostgreSQL with pgvector instead of a dedicated vector database (Pinecone, Qdrant, Weaviate)? For a few hundred vectors, a separate service adds infrastructure complexity with no performance benefit. pgvector runs inside the existing database, uses the same backup system, and eliminates one more thing to deploy and monitor.

Product Sync from the Source of Truth

The chatbot never stores product data manually. A daily sync task reads from the company's existing CMS, maps products to a normalized schema, upserts by product ID, and deactivates removed records. When the company adds a lender or a rate changes, it happens in the CMS — the chatbot picks it up the next morning without any chatbot-specific work.

Product matching is entirely deterministic: filter by product type, amount range, credit history, and employment status. The AI is not involved. Interest rates and product eligibility are never at risk of hallucination.

Page Context and Smart Auto-Skip

The widget reads the current page URL on load. A user landing on /mortgages/ is probably interested in a mortgage. This gets stored in the session immediately.

When the conversation tree reaches the "What product are you looking for?" node, the Orchestrator detects the pre-known answer and skips the question — but asks for confirmation first:

"I see you're interested in a mortgage. Is that right?"

If confirmed, the conversation jumps ahead. If not, the question is asked normally and the pre-filled value is discarded. The same pattern applies to returning visitors who already answered some questions in a previous session.

Messenger as a Channel

The same engine powers both the web widget and a messaging bot (we use Telegram; WhatsApp Business API works identically in principle). When a user wants to continue the conversation in their preferred messenger, the widget generates a session transfer token and opens the bot with a deep link. The bot claims the token and picks up exactly where the web conversation left off — same graph, same collected data, same product matches. The bot also ingests the company's social channel posts into the same RAG knowledge base, giving the Info Agent access to announcements and promotions alongside the blog.

What It Actually Costs

Running at roughly 10,000 conversations per month (we use a regional LLM provider; costs below use GPT-4o equivalents for reference):

Component	Monthly cost
VPS (shared with other projects)	~$5
LLM API — Orchestrator + Info Agent (GPT-4o class)	~$42
LLM API — Parser (GPT-4o-mini class, 40% cached)	~$11
Embeddings (ingestion + search)	~$2.50
Total	~$60/month

The comparable Intercom configuration — 5 agents, Fin AI, similar conversation volume — would run $1,400–$1,600/month, plus one-time setup costs.

The tradeoff is upfront development time. This isn't a weekend project. It took several months of focused engineering to build the conversation graph, integrate with the CRM, implement the RAG pipeline, and wire up the messaging bot. For a business that can afford the investment, the long-term economics are clear.

Which Approach Is Actually Right for You?

Four options, honest about what each one is:

Pure prompt bot ($20–$500/month):
Use this if you need simple FAQ coverage, your entire knowledge base fits in a short prompt, you have no compliance exposure, and you understand you're accepting hallucination and guardrail risk. Good for proof of concept. Not good for financial services, healthcare, legal, or any domain where the bot's wrong answer has consequences.

SaaS platform ($100–$2,500+/month):
Use this if you primarily need FAQ deflection and ticket routing, your product catalog is stable and simple, you have a support team that wants a unified inbox, and you want to be running in days. Intercom Fin and Zendesk AI Agents are genuinely good at what they do. The per-resolution pricing is painful at scale but may be worth it for teams that would otherwise need to hire.

Open-source framework (Rasa/Botpress, $0 software + infra + engineers):
Rasa gives you full control with self-hosted NLU and dialogue management. It requires a Python engineer and real training data. Enterprise licensing starts at $35,000/year. Botpress has become increasingly LLM-first with a visual builder and code escape hatches — worth evaluating if you want something between no-code and fully custom. Both require ongoing maintenance that SaaS absorbs for you.

Custom hybrid (engineering investment + $50–$100/month API costs):
Use this if you need guided multi-step qualification flows, product data that stays synchronized with an existing system, data residency or compliance requirements (GDPR, HIPAA, FCA), non-standard channel integration, or long-term cost predictability. Not a weekend project — but at scale, the economics are clear. Expect fully-loaded engineering costs of $40K–$150K to get to production.

A rough decision matrix:

	Prompt bot	SaaS	Open source	Custom hybrid
Time to deploy	Hours	Days	Weeks	Months
Upfront cost	$0–$800	$0–$30K	$0 + dev time	$40K–$150K
Monthly cost	$20–$500	$100–$2,500+	Infra + salaries	$50–$150
Hallucination risk	High	Low–medium	Low–medium	Low (rule-based core)
Business logic enforcement	None	Partial	Yes	Yes
CRM integration	None	Via webhooks	Custom	Native
Session memory	None	Yes	Yes	Yes
Compliance / data residency	Risky	Complex	Manageable	Full control
Best for	FAQ / PoC	Support teams	ML-heavy use cases	Complex sales/qualification

The Honest Tradeoffs

What hybrid gets you:

Predictable monthly costs that don't spike with conversation volume
Complete control over conversation flow and business logic
Data stays in your infrastructure
Product matching is deterministic — no hallucinated interest rates
AI handles what it's good at: understanding natural language and synthesizing knowledge base answers

What you give up:

A polished multi-agent inbox for your support team (build or integrate separately)
The "set it up in a week" promise of SaaS
Automatic updates as LLM providers improve
Someone else's engineering team maintaining the underlying platform

The lingering questions:
The SaaS platforms are improving fast. Intercom Fin and Zendesk AI Agents are significantly better than they were a year ago. The per-resolution pricing is painful now but may normalize. For many businesses, the build option will stop making sense as the platforms mature.

The differentiator that won't go away is data and compliance. If your business collects sensitive personal information and operates under regulatory requirements, you need to know exactly where that data goes. SaaS platforms can claim GDPR compliance, but the actual data processing location and sub-processor chain is complex. For fintech, healthcare, and legal services, that complexity carries real risk.

What We Learned

Building a chatbot is not primarily a technology problem. The technology — conversation graphs, LLM APIs, vector search — is well-understood and accessible. The real work is conversation design: figuring out what to ask, in what order, with what fallbacks, and what to do when users say something you didn't anticipate.

The hybrid approach forced us to be explicit about every step of the conversation. Every node in the graph is a decision. Every quick-reply option is a commitment. That explicitness is a feature — it means the chatbot's behavior is auditable, testable, and predictable. You can read the graph and understand exactly what the bot will do in any situation.

Pure LLM chatbots are flexible in ways that can be dangerous for financial advice: they'll confidently answer questions outside their knowledge base, recommend products that don't exist, or skip qualification steps that matter for compliance. The graph prevents that class of error entirely.

The cost math works in our favor today. Whether it still will in two years depends on how LLM pricing evolves and how good the SaaS platforms get at respecting data boundaries. Both are moving fast.

Built with Django, PostgreSQL + pgvector, and vanilla JavaScript.

SEO Is a Marathon: How AI Agents Can Help You Stay the Course

Sergey — Thu, 05 Feb 2026 10:09:46 +0000

TL;DR: I built an open-source template for managing SEO projects with Claude Code. It includes slash commands for session management, data analysis, and content review. First results: 10+ comprehensive long-form articles—better quality than pre-agentic AI writers, cheaper than human copywriters. Free tools for position tracking. Get it on GitHub.

SEO success doesn't come from a single burst of effort. It's months of consistent work: researching keywords, writing articles, analyzing performance, adjusting strategy, and repeating. It's tedious and time-consuming work. For running businesses, it's usually outsourced to SEO professionals (and it isn't cheap). Most startups give up not because SEO doesn't work, but because the grind wears them down before results show.

What if AI could handle the repetitive parts while you focus on strategy and creativity?

For the past year, I've used Claude Code as an integrated part of my e-commerce SEO workflow - not for one-off tasks, but as a consistent assistant across months of work. First results: it's nearly free beyond the Claude Code subscription, 10+ articles published, monthly reporting reduced from 2 hours to 15 minutes, and a content audit process that now runs in seconds instead of days.

Here's what I learned, plus the open-source template that makes this approach reproducible.

The Reality of SEO Work

Let's be honest about what SEO actually involves:

Phase 1-3: Research (Weeks 1-4)

Audit your current site
Research 100-200 keywords
Analyze 3-5 competitors
Build a content strategy

Phase 4-6: Execution (Months 2-6)

Write 5-10 articles per month
Optimize existing pages
Build internal links
Submit to search engines

Phase 7-8: Maintenance (Ongoing)

Track rankings weekly
Analyze performance monthly
Update underperforming content
Build external links

Each phase has repetitive tasks. Keyword research means running the same queries across multiple tools. Writing follows templates. Performance analysis requires pulling data from the same sources and comparing against the same benchmarks.

This is where AI agents excel: consistent execution of well-defined tasks.

What "Agentic" Means Here

I'm not just talking about AI writing your articles (though it requires your input). I'm talking about AI handling the full workflow around content:

Session management: Loading context at start, saving progress at end
Data analysis: Processing Yandex Webmaster and Google Search Console exports
Quality control: Running multiple critics on drafts before publishing
Report generation: Creating monthly performance reports from templates
Content audit: Scanning your site for gaps and opportunities

These tasks add up. Analyzing a month's search console data might take 30 minutes manually. With a well-crafted prompt, it takes seconds.

The Template Structure

Here's how I organize an AI-assisted SEO project:

.claude/
├── context/           # Current state
│   ├── active-context.md    # This sprint's priorities
│   └── progress.md          # What's done, what's next
├── memory/            # Long-term knowledge
│   └── memory-bank.md       # Strategic insights
├── skills/            # Slash commands
│   ├── start-session/
│   ├── end-session/
│   ├── monthly-report/
│   └── analyze-webmaster/
└── workflows/         # Process docs
    ├── SEO_WORKFLOW.md
    └── CONTENT_WRITING_GUIDE.md

scripts/
└── content_audit/     # Python utility
    └── main.py

content/
├── drafts/
├── published/
└── calendars/

research/
├── keywords/
├── analytics/
└── content-audit/

The .claude/ directory is the key. It contains everything the AI needs to understand your project and execute tasks consistently.

Slash Commands (Skills)

Claude Code supports "skills" - custom prompts that can be invoked with /command. Here are the ones I use daily:

/start-session

Loads project context at the beginning of work:

Reads active priorities
Checks progress status
Loads memory bank
Provides status summary

/end-session

Saves progress and commits changes:

Updates progress tracking
Commits to git with detailed message
Provides session summary

/analyze-webmaster

Processes Yandex Webmaster exports:

Analyzes queries, pages, devices, geography
Identifies growth opportunities
Generates detailed report

/monthly-report

Generates monthly performance report:

Creates template from structure
Sets up data snapshot directory
Provides checklist for data collection

/review-article

Runs multiple critics on content:

SEO compliance check
Language quality (native-level review)
E-E-A-T signals
User intent satisfaction
Readability analysis
Commercial integration

This last one is particularly useful. Instead of hoping your article is good, you get structured feedback from multiple perspectives before publishing.

Want to try it? Clone the template and run /start-session to see it in action.

The Content Audit Utility

Beyond Claude Code skills, the template includes a Python utility for site-wide content analysis:

cd scripts/content_audit
python main.py --full

This scans your sitemap, extracts content, and generates:

Site-wide content inventory (CSV)
Gap analysis (keywords you're missing)
CTR optimization opportunities
Cannibalization detection (pages competing for the same keywords)

The output integrates with Google Search Console and Yandex Webmaster data for a complete picture.

Required Input and How to Get It

This data could be obtained via API in future releases, but for now the workflow requires data from several sources:

Data	Source	How to Get
Keywords	Yandex Wordstat, Ahrefs, SEMrush	Export to CSV
Search performance	Google Search Console, Yandex Webmaster	Download reports
Site content	Your sitemap	Automatic via Python script
Competitor data	Manual research	Document in research/

The template includes clear locations for each data type and instructions for processing.

What This Doesn't Do

Let's be honest about limitations:

Won't write final articles without your input: AI drafts still need human input and polishing
Won't guarantee rankings: SEO fundamentals still apply
Won't replace expertise: You need to understand SEO to direct the AI
Won't generate images for you: It will provide prompts for AI generation, but Claude lacks image generation

This is a productivity multiplier, not a magic solution.

Getting Started

1. Clone the Template

git clone https://github.com/stikhonchuk/ai-seo-workflow.git my-seo-project
cd my-seo-project
rm -rf .git && git init

2. Configure for Your Project

cp scripts/content_audit/config.example.py scripts/content_audit/config.py
# Edit config.py with your domain

3. Update Context Files

Replace placeholders in:

.claude/context/active-context.md
.claude/context/progress.md
.claude/memory/memory-bank.md

4. Start Using

claude  # Start Claude Code
/start-session  # Load context

That's it. The template handles the rest.

Multi-Project Architecture

If you want to contribute to the project, the template supports a hub-and-spoke model:

┌─────────────────────────────────────┐
│    PUBLIC TEMPLATE (ai-seo-workflow) │
│    - Generic workflows               │
│    - Shared scripts                  │
│    - Community improvements          │
└─────────────────────────────────────┘
         ▲                    ▲
         │ cherry-pick        │ cherry-pick
         │ (anonymized)       │ (anonymized)
         │                    │
┌─────────────────┐   ┌─────────────────┐
│   project-a     │   │   project-b     │
│   (private)     │   │   (private)     │
└─────────────────┘   └─────────────────┘

Improvements flow both ways:

Template updates → private projects via git pull upstream
Private improvements → template via anonymize + cherry-pick

An anonymization script (scripts/anonymize.py) helps prepare files for public contribution by replacing project-specific data with placeholders.

Work in Progress

This template is actively evolving. Current areas of development:

[ ] Better integration with Google Analytics 4
[ ] Image generation prompt templates
[ ] Link building workflow automation
[ ] Multi-language content support

Contributing

If you try this workflow and improve it, contributions are welcome:

Fork the repository
Make your changes
Run python scripts/anonymize.py --check . to ensure no private data
Submit a pull request

Even bug reports and documentation improvements help.

Why Open Source This?

Three reasons:

Forced better documentation: Knowing others will use it makes you document properly
Community improvements: Others might solve problems I haven't encountered
Reference implementation: Shows one way to structure AI-assisted workflows

The unique value isn't the SEO advice (plenty of that exists). It's the integration pattern: how to make AI a consistent part of a long-running project, not just a one-off tool.

FAQ

Do I need Claude Pro/Max subscription?
Claude Code requires subscription or API access, so you'll need an Anthropic API key with credits. The template itself is free.

Can I use this with ChatGPT or other AI tools?
The skills are written for Claude Code specifically, but the workflow structure (context files, memory bank, progress tracking) could be adapted to other tools.

What if I don't use Yandex Webmaster?
The template includes Google Search Console analysis too. Yandex-specific features are optional.

Repository: github.com/stikhonchuk/ai-seo-workflow

Built with: Claude Code by Anthropic

This is v1.0 of the template. I've been using variations of this workflow for a year. The public version is new and likely has rough edges. Feedback appreciated.