DEV Community: Jay Guthrie

Deploy a Telegram Bot with Persistent MemoryHow I Built an Autonomous X Reply Agent with Zero API Costs

Jay Guthrie — Tue, 17 Mar 2026 21:27:42 +0000

I needed my product (vaos.sh) to show up in every conversation about OpenClaw memory problems on X. Manually finding and replying to tweets was eating 2 hours a day. So I built a system that does it autonomously.

The Stack

Bird CLI — free X search using browser cookies (no paid API)
Codex CLI — GPT-5.4 via my ChatGPT Pro subscription (unlimited tokens, $0 extra)
Chrome CDP — browser automation for posting (bypasses X API restrictions)
Supabase — event bus for tracking what's been replied to
Humanizer rules — anti-AI-slop prompt engineering

Total cost beyond my existing ChatGPT Pro subscription: $0.

How It Works

Every 30 minutes, the system:

Picks a random search query from 15 OpenClaw-related topics
Searches X via bird CLI (free, uses browser cookies)
Filters out tweets I've already replied to
Sorts by engagement (likes + replies)
Sends the tweet to GPT-5.4 via Codex with humanizer rules
GPT drafts a reply under 180 characters that sounds like a tired builder texting at 2am
Posts via Chrome CDP with the account already logged in
Logs to Supabase event bus

The Humanizer Prompt

The key insight: LLM-generated replies sound like LLM-generated replies. The humanizer rules fix this:

No significance inflation or promotional language
No em dashes (the #1 AI tell)
No chatbot phrases ("Great question!", "I hope this helps")
Vary sentence length. Short punchy. Then longer.
Have opinions. React, don't report.
Sound like a person texting, not a brand

Example output: "Yeah, stuffing everything into MEMORY.md is a dead end. Context bloats, the agent gets dumb, and you spend half your time re-explaining the repo."

That reads like a human. Because the prompt told the LLM to write like one.

Results

Day 1: The system found and replied to a tweet with 127 likes and 32 replies. The reply was contextually relevant, under 160 characters, and sounded natural.

The system runs via macOS launchd (like cron but persistent). It survives reboots. No server needed.

What I'd Do Differently

Add engagement tracking so the system learns which reply styles get likes
Route replies through a Critic agent that rejects anything too promotional
Add multi-platform support (LinkedIn, Reddit)

The code is part of the VAOS infrastructure at vaos.sh. The agent hosting platform gives your AI persistent memory and behavioral corrections — the same tech that powers this reply system.

*Follow the build in public journey: @StraughterG*Telegram bots are the fastest way to get an AI agent into someone's hands. No app store approval. No web hosting. No frontend to build. The user opens Telegram, sends a message, gets a response.

The problem is that most Telegram bot frameworks give you a stateless loop. Message comes in, response goes out, everything is forgotten. Your bot treats every conversation like meeting a stranger for the first time.

What you need

A Telegram bot token (from @botfather)
A model API key (OpenAI, Anthropic, Google — pick one)
Somewhere to run it 24/7

The "somewhere to run it" part is where most people get stuck. You can use a VPS, but then you're managing uptime, SSL, process managers, and deployments. Docker helps but adds its own complexity. Kubernetes is overkill for a single bot.

The 60-second version

VAOS handles the infrastructure:

Sign up at vaos.sh
Paste your Telegram bot token
Pick a model
Your bot is live

No Docker. No VPS. No process manager. The bot runs on Fly.io infrastructure with automatic restarts, health checks, and monitoring.

What makes this different from a basic bot

Three things your Telegram bot gets automatically:

Memory. After each conversation, VAOS extracts facts and stores them. Next time the user messages, the bot remembers their name, their project, their preferences. This happens without you writing any code.

Self-correction. When the bot says something wrong, you click "correct this" in the dashboard and write what it should have said. That correction becomes a rule injected at boot. The bot won't make that specific mistake again.

Observability. Every message, every response, every trace is logged. You can see exactly what your bot said, why it said it, and how confident it was. PostHog analytics, Sentry error tracking, and Opik traces come built-in.

The catch

Cold start. For the first few days, the bot doesn't have enough data to be smart. It needs conversations to extract memories from and mistakes to learn corrections from. Plan to actively use it (or have a few testers use it) for the first week.

Also: right now VAOS only supports Telegram. Discord and WhatsApp are coming but aren't hooked up yet.

When to build it yourself

If you need full control over the bot's behavior, custom integrations, or you're running at scale (thousands of concurrent users), build it yourself. The OpenClaw framework is open source and gives you everything you need.

If you want the bot running in under a minute with memory and self-correction built in, use VAOS. 14-day free trial at vaos.sh.

The goal is the same either way: a Telegram bot that gets smarter over time instead of staying exactly as dumb as it was on day one.

Stop Your AI Agent From Hallucinating Features

Jay Guthrie — Tue, 17 Mar 2026 18:49:50 +0000

A user asks your customer support bot "do you support WhatsApp?" Your bot says "Yes! You can connect WhatsApp in the settings page." You don't support WhatsApp. There is no settings page.

This happens constantly with LLM-based agents. The model wants to be helpful. It fills in gaps with plausible-sounding answers. In a chatbot context, "plausible-sounding" means promising features that don't exist.

Why fine-tuning doesn't fix this

The instinct is to fine-tune: train the model on your actual product docs so it knows what's real. Three problems:

Fine-tuning is expensive and slow. Every product update means retraining.
The model can still hallucinate outside the training data. Fine-tuning reduces frequency, it doesn't eliminate it.
You can't inspect what the model "learned." It's a black box.

What works: a "cannot claim" list

Keep a list of things your agent is NOT allowed to say. Not what it should say — what it must never claim.

Examples:

"Never say WhatsApp is supported"
"Never mention a settings page"
"Never claim we offer a free plan" (if you don't)
"Never say data is encrypted at rest" (if it isn't)

This list gets injected into the system prompt at boot. Every time the agent starts, it knows what's off-limits. When you catch a new hallucination, add it to the list. The list grows over time and the hallucinations shrink.

Automated correction capture

The manual approach: you read transcripts, spot hallucinations, and add rules. This works for 10 conversations. It doesn't work for 1,000.

The automated approach: flag low-confidence responses for human review. When a human corrects one, the correction is automatically stored as a rule. Next boot, the agent has the new rule.

This is the approach we built into VAOS. Confidence scoring tags each response with a 0-1 score. Below the threshold, it gets queued. Above, it auto-approves. The threshold is adjustable per use case — a social media bot can tolerate more uncertainty than a medical information bot.

The compound effect

Each correction makes the next conversation slightly better. After a few weeks, your agent stops making the same mistakes. The first version of our test agent (Scribe) was embarrassingly bad. After about 80 corrections, it became reliable for its use case.

The corrections are just data. JSON objects with a rule, a reason, and a timestamp. You can export them, version them, bring them to another provider. No lock-in.

Try it

If you're running an AI agent that hallucinates features, try VAOS. It traces every conversation, flags uncertain responses, and turns your corrections into permanent rules. 14-day free trial at vaos.sh.

Or build the correction system yourself. The pattern is simple: catch the mistake, store the rule, inject at boot, repeat. The tool matters less than the loop.

How to Give Your AI Agent Memory Between Conversations

Jay Guthrie — Tue, 17 Mar 2026 18:49:37 +0000

Your AI agent handles a great conversation. The user explains their project, their preferences, their constraints. Then the session ends. Next time they message, the agent has no idea who they are.

This is the single most common complaint from anyone running AI agents in production. The model is stateless. Every conversation starts from zero.

Why prompt stuffing breaks down

The obvious fix is cramming conversation history into the system prompt. It works until it doesn't. Context windows have limits. Old conversations get truncated. You're paying for tokens you've already processed. And the agent still can't distinguish between "things to remember forever" and "things that were only relevant in that one conversation."

What actually works: structured memory extraction

Instead of keeping raw conversation logs, extract specific facts. "User's name is Sarah." "User prefers Python over JavaScript." "User's project is a healthcare chatbot." These are discrete, searchable, and cheap to inject.

The extraction should happen automatically after each conversation. Not manually. If you're asking a human to tag memories, it won't scale past 10 conversations.

The cold start problem

The hard truth: memory-based systems are useless on day 1. Your agent needs enough conversations to build a useful memory bank. In our experience with VAOS, it takes about 80 interactions before the quality jump becomes obvious. The first few days feel like you're doing QA for free.

Two ways to shorten cold start:

Seed with 5-10 reference interactions before going live
Pre-load known facts about your use case (industry terms, common questions, product details)

Corrections as structured context

When your agent gets something wrong, the correction shouldn't disappear. It should become a permanent rule: "Never recommend product X to users on the free plan." "Always mention the 14-day trial when asked about pricing."

These corrections accumulate over time. Each one makes the agent slightly better. After a few weeks, the agent stops making the mistakes you've already corrected.

This isn't fine-tuning. Fine-tuning is expensive, brittle, and hard to debug. Structured corrections are inspectable, portable, and versioned. If you switch providers, your corrections come with you.

Implementation

If you want to build this yourself:

After each conversation, run a summarization pass that extracts key facts
Store facts in a database with timestamps and source conversation IDs
On each new conversation, inject relevant facts into the system prompt
When the agent makes a mistake, store the correction as a rule
Inject active rules alongside memories at boot

Or use VAOS, which does all of this automatically. Every conversation is traced, memories are extracted, and corrections become rules injected at boot. 14-day free trial at vaos.sh.

The point isn't the tool. The point is that stateless agents are broken, and the fix is structured memory, not bigger context windows.

The Complete Guide to AI Agent Observability in Production

Jay Guthrie — Tue, 17 Mar 2026 17:56:09 +0000

You've been there. Your AI agent was sailing along, answering questions, handling tickets, helping users. Then Tuesday happened. Users start reporting weird answers. You check the logs and... nothing looks wrong. The requests look fine. The context window isn't full. But something is off.

By Friday you're knee-deep in debug output, realizing you have no idea what your agent actually said to 47 people on Wednesday.

That's the observability gap. Most AI tooling gives you traces, latency, token counts. It tells you the request succeeded. It does not tell you whether the agent hallucinated, contradicted itself, or forgot a critical instruction.

This guide covers how to build observability for AI agents in production. Specifically for solo builders and small teams who can't afford an engineering team to babysit their monitoring stack.

What Observability Means for AI Agents

Traditional monitoring is about uptime and performance. Is the service running? Are requests completing within SLA? How many 500 errors?

AI agents need a different dimension: behavior. Is the agent staying within bounds? Is it drifting from its training? Is it confidently stating things that are wrong?

Consider this: a standard monitoring dashboard shows you request volume, latency, and error rate. Your agent runs 10,000 requests per day with 0.5% 5xx errors. Everything looks green.

Meanwhile, the agent started hallucinating discount codes on Tuesday afternoon. It gave free premium access to 300 users. Your monitoring stack never flagged it because there were no errors—just confidently incorrect behavior.

That's the observability gap.

The Three Pillars of AI Agent Observability

1. Visibility into Responses

You need to see what your agent actually outputs. Not just tokens generated or time to first token. You need to read the full response, compare it against rules, and surface anomalies.

This seems obvious, but a lot of teams skip it. They set up logging for the system around the agent—HTTP status codes, database calls, external API timing—but not the agent itself.

Here's the problem: when your agent hallucinates, the HTTP request returns 200 OK. Your error rate stays zero. The logs show nothing unusual. Without seeing the actual responses, you're flying blind.

2. Behavioral Rule Enforcement

You need rules that run after the response but before it reaches the user. Rules like:

Never mention competitor pricing
Never promise features that don't exist
Never share internal data
Never escalate to human for these specific queries

These rules need to be configurable, versionable, and testable. Hardcoded if statements scattered through your codebase don't scale.

3. Feedback Loops

Users will tell you when your agent is wrong. But if you don't capture that feedback, you're burning signal. You need a way to tag conversations as "good" or "bad," understand why, and feed that back into your system.

This isn't just thumbs-up/thumbs-down. It's structured feedback: "the agent was too aggressive," "it missed a key requirement," "it contradicted the documentation." Without this, you're guessing at what to fix.

What Most People Get Wrong

Mistake 1: Logging Everything, Understanding Nothing

You enable verbose logging on every component. Your agent logs the prompt, the context, the model response, the post-processing steps, the database queries. Your logs grow at 500MB per day.

Then someone asks "what happened with the discount code hallucination on Tuesday?" and you stare at a wall of JSON for three hours.

Observability isn't logging everything. It's logging the right things in a way you can actually query and understand.

Mistake 2: Treating LLM Errors Like HTTP Errors

When a database query fails, you log the error, maybe alert on elevated error rates, and investigate. When an LLM hallucinates, there's no error. The request completed successfully. The agent is just wrong.

You need different alerting for behavioral anomalies, not just system failures. A spike in flagged responses is as important as a spike in 500 errors.

Mistake 3: One-Off Fixes Instead of Systemic Rules

Your agent hallucinates about a feature. You add a specific check: "if prompt mentions [feature], prepend 'this feature does not exist.'"

Three weeks later it hallucinates about a different feature. You add another check. Your codebase becomes a graveyard of one-off patches.

You need a rules engine, not a collection of edge cases.

Building Observability: Step by Step

Step 1: Capture the Full Conversation

This sounds trivial but teams miss it. They log the user message and the agent response. They don't log:

The system prompt
The context injected (retrieved documents, database lookups, previous messages)
The tool calls made and their results
The intermediate reasoning if you're using chain-of-thought
Post-processing steps (formatting, filtering, rewriting)

If you don't capture this, you can't debug. You can't reconstruct what happened. You can't reproduce issues.

Step 2: Define Your Behavioral Rules

Start with the basics. What must your agent never do?

Never disclose internal metrics or unreleased features
Never contradict the official documentation
Never use profanity or offensive language
Never make financial promises beyond what's documented
Never claim authority it doesn't have (like "I'm a lawyer")

These rules should be defined declaratively, not imperatively. A configuration file beats hardcoded logic because you can iterate without shipping code.

Step 3: Run Rules Before Sending to Users

This is the guardrail pattern. Your agent generates a response, then your rules engine evaluates it. If a rule fires, you have options:

Block the response and send a fallback ("I'm not sure about that")
Modify the response to remove the offending content
Escalate to human review
Allow but flag for manual review

Which you choose depends on the risk. Financial promises? Block. Tone violations? Maybe allow and flag. Contextual misunderstandings? Allow and learn.

Step 4: Capture User Feedback

Every interaction should have a feedback mechanism. Thumbs up/down is better than nothing, but structured feedback is better.

The issue with binary feedback: you know the user was unhappy, but you don't know why. Was it factual inaccuracy? Tone? Irrelevance? Too verbose? Not specific enough?

Better: ask users what went wrong. "What was wrong with this response?" with quick categories like "incorrect information," "confusing," "too long," "rude tone." You can iterate on these categories as you learn what matters for your use case.

Step 5: Build Dashboards That Matter

Here's what your dashboard should show:

Response rate flagged by rules (percentage)
Top rule violations over the last 7 days
User sentiment trend (thumbs up/down ratio)
Average response time
Context window utilization (are you hitting limits?)

What you probably don't need:

Token count per request (too granular, rarely actionable)
Per-user response breakdown (privacy issues, rarely actionable)
Real-time request waterfall (debugging tool, not monitoring)

When Your Agent Gets Dumber

One of the scariest things in production: your agent gets worse over time and you don't notice until users complain.

This happens for a few reasons:

1. Context Window Bloat

You accumulate more context over time. More documentation, more previous messages, more retrieved data. Eventually your agent's prompt is 90% boilerplate and 10% actual user question.

You need to monitor context window utilization and trim aggressively. Remove redundant messages. Summarize older messages instead of storing full history. Drop irrelevant retrieved documents.

2. Distribution Shift

Your users ask different questions over time. Maybe you launched in a new market, or added a feature, or your marketing brought in a different audience. The agent trained on old patterns doesn't work as well on new patterns.

Monitor query similarity. If today's questions look substantially different from last month's, you may need to update your examples, retrieve different context, or fine-tune.

3. Prompt Drift

You updated your system prompt three weeks ago to fix a specific issue. That change had side effects you didn't anticipate. The agent is now too conservative in a different context.

Version your prompts. When you make a change, monitor metrics before and after. If something got worse, you can roll back.

Advanced: Confidence Scoring

This is where observability gets interesting. What if you could tell when your agent is about to say something wrong?

Confidence scoring is a pattern where you:

Generate the agent response
Ask a second model: "how confident are you this response is correct?"
If confidence is low, either block or escalate

This isn't perfect. Models are bad at self-evaluation. But it's better than nothing, and it catches cases where the agent is hallucinating confidently.

The key insight: hallucinations often come with high confidence. The model doesn't know it's wrong—it's just confidently generating plausible-sounding nonsense. A second model, specifically trained to evaluate confidence, can often spot the disconnect.

Tools vs. Building It Yourself

You can build observability yourself. It's not rocket science:

Log everything to a database (Postgres, MongoDB, whatever)
Build a rules engine (simple if statements or a more flexible pattern matcher)
Build dashboards (Grafana, Metabase, even a simple admin panel)

The question is: is that the best use of your time?

Consider the tradeoffs:

Building yourself:

Pros: complete control, no vendor lock-in, zero cost beyond infrastructure
Cons: engineering time, maintenance burden, reinventing wheels

Using a tool:

Pros: battle-tested features, faster setup, ongoing improvements
Cons: monthly cost, vendor lock-in, may not fit your exact needs

For solo founders or small teams, the math usually favors tools. Your time is too valuable to spend building a second-rate observability stack when you could be shipping features.

A Practical Monitoring Stack

Here's what I'd recommend for a solo builder running an AI agent in production:

Logging

Structure your logs as JSON
Include: timestamp, user_id (hashed), conversation_id, full_prompt, full_response, rule_violations (if any), user_feedback (if any)
Ship logs to a searchable database or log aggregation service

Rules Engine

Start with a simple configuration file defining your behavioral rules
Implement rule evaluation in your application code
Log every rule violation with the rule name and the offending content

Dashboards

Build at least three views:
1. High-level overview (response rate, flagged percentage, user sentiment)
2. Rule violations breakdown (which rules fire most often)
3. Recent flagged conversations for manual review

Alerts

Alert on: spike in flagged responses, spike in thumbs-down, drop in response rate, any critical rule violation (like financial promises)

This doesn't require enterprise tools. You can do it with open source software and a weekend of setup.

What VAOS Does Differently

Full disclosure: I built VAOS because I got tired of doing this manually.

The problems I ran into:

My agent worked great for two weeks, then started hallucinating discount codes
I couldn't find the conversation where it first happened because my logs were unstructured
I added one-off fixes to prevent the hallucination, but similar issues kept cropping up
User feedback was scattered across channels (emails, tickets, Discord messages)
I spent more time debugging than building

VAOS is built for this specific problem set. It:

Captures full conversation context including system prompts and tool calls
Runs configurable behavioral rules before responses reach users
Centralizes user feedback across channels
Provides dashboards focused on what matters for AI agents (behavior, not just uptime)
Alerts on behavioral anomalies, not just system failures

If you're a solo builder running an AI agent in production, you don't need enterprise observability. You need something that catches hallucinations before your users do.

Common Questions

Do I need observability if I'm just experimenting?

No. Observability adds overhead. If you're in the prototype phase, ship features, iterate, worry about monitoring later. When you have real users depending on your agent, that's when observability matters.

Can't I just use OpenAI's usage dashboard?

OpenAI tells you how much you're spending. It doesn't tell you whether your agent is hallucinating. Those are different problems.

What about privacy?

Log the prompts and responses, but hash user identifiers. Store minimal PII. If you're in a regulated industry (healthcare, finance), you may need additional controls.

How much does this cost to run?

Depends on your scale. For 10,000 requests per day, storing full conversations in Postgres will cost you maybe $10-20/month in storage. Add a few dollars for dashboard infrastructure. Not expensive.

When should I upgrade to a dedicated tool?

When your current approach is holding you back. Common signals:

You can't find issues because logs are unstructured
You have too many one-off rules scattered across code
You're spending more than a few hours per week on monitoring
User feedback is fragmented and hard to act on

Getting Started Today

If you're running an AI agent in production without observability, here's what to do this week:

Day 1: Add structured logging to capture full prompts and responses
Day 2: Define your top 5 behavioral rules and implement basic checking
Day 3: Add a simple thumbs-up/thumbs-down mechanism to your UI
Day 4: Build a basic dashboard showing flagged conversations and user sentiment
Day 5: Set up an alert for spike in flagged responses

This is not rocket science. You can do it in a weekend. The alternative is discovering a major hallucination from a customer complaint.

The Bottom Line

Your agent worked yesterday. Today it's hallucinating. Tomorrow it will do something else unexpected.

Observability isn't optional for production AI agents. It's the difference between catching issues early and finding out from angry users.

You don't need enterprise tools. You don't need a team of engineers. You need to see what your agent is actually saying, define the rules it must follow, and catch problems before they escalate.

Build that, and your agent will stop being a mystery you're afraid to touch.

Want to see what this looks like in practice? Check out VAOS pricing for a production-ready observability stack built specifically for AI agents.

I Built a 7-Agent AI Marketing Crew: 235 Replies, Zero Revenue

Jay Guthrie — Tue, 17 Mar 2026 17:46:12 +0000

I'm a rookie founder. I sell managed OpenClaw hosting at vaos.sh. Your agent gets persistent memory and behavioral corrections — it remembers everything and learns from mistakes. $29/month, deploy in 60 seconds.

Problem: nobody knew it existed. Zero customers. Zero signups. Zero email captures.

So instead of doing manual outreach, I built an autonomous marketing machine. Here's what happened.

The Old Setup (3 Agents Doing 7 Jobs)

I started with three agents:

Scout — found leads on X using keyword searches
Scribe — drafted and posted replies
Trinity — scored engagement and adjusted strategy

It worked... sort of. Scribe posted 205 replies in 3 days. But the quality was inconsistent. Some replies sounded like a bot. Some mentioned the product in every single reply. The X algorithm noticed — 133 replies in one day got my account suppressed. Impressions dropped from 10-100 per tweet to 0-2.

Trinity detected the suppression and issued an emergency protocol: zero product mentions until the account recovered. Smart move by the system, but it meant the machine was generating pure engagement with no business results.

The New Setup (7 Agents, 1 Job Each)

I redesigned the pipeline with 7 specialized agents:

Researcher — finds people struggling with OpenClaw on X (using bird CLI, no API costs)
Qualifier — scores leads 1-10, kills bad ones. Only leads scoring 6+ get through
Writer — drafts replies in my voice. Uses a humanizer skill to sound natural
Critic — reviews every draft before it goes live. Blocks anything bot-like or repetitive
Converter — decides when to mention the product (1 in 3 replies, naturally woven in)
Distributor — posts via Chrome browser automation with human-like typing speed
Analyst — scores engagement, updates strategy, feeds learnings back to the crew

Each agent talks to the next through an event bus (Supabase). Researcher writes lead.found, Qualifier reads it and writes lead.qualified, Writer reads that and writes reply.drafted, and so on.

The Tech Stack

Model: OpenAI GPT-5.3 Codex via ChatGPT Pro subscription ($0 extra API cost)
Orchestration: OpenClaw cron jobs, each agent fires on a schedule
Search: bird CLI (free, uses browser cookies, no paid X API)
Posting: Chrome CDP browser automation with per-character typing, random mouse movements, scroll simulation
Event bus: Supabase agent_events table
Monitoring: Custom dashboard querying Supabase + PostHog
Infrastructure: 1 Mac Mini

Total cost beyond the ChatGPT Pro subscription I already had: $0.

The Numbers (Honest)

After 3 days of running:

235+ replies posted autonomously across X
9 qualified leads found in the latest run
1,300 followers on the account
9.7% engagement rate (up 66% from before)
0 paying customers
0 email signups
$0 MRR

The machine works. It finds real people with real problems, writes replies they actually engage with, and posts them without me touching anything. But it hasn't converted a single person into a customer yet.

What I Learned

1. Specialization beats generalization

3 agents trying to do 7 jobs produced mediocre results across the board. 7 agents doing 1 job each produced noticeably better quality. The Critic alone killed 40% of drafts before they went live — drafts that the old system would have posted.

2. The Critic is the game changer

Without a quality gate, your autonomous system will post garbage. The Critic checks every draft against recent replies (no repetition), evaluates whether it sounds human, and rejects anything that could get the account flagged. This single agent probably saved the account from permanent suppression.

3. 133 replies in one day will get you suppressed

X's algorithm watches for burst patterns. When Scribe posted 133 replies in one day from the same IP at regular intervals, the account got shadow-suppressed. Impressions dropped to near-zero. It took days of pure engagement (zero product mentions) to recover.

4. The machine needs human-like behavior

The posting script now simulates reading the tweet first (random scroll, mouse movement), then types character-by-character at variable speed with occasional pauses, then clicks reply. The difference between "dump text instantly" and "type like a human" is the difference between being flagged and being invisible.

5. Revenue requires more than engagement

235 replies generated engagement. People liked them, replied back, had conversations. But engagement alone doesn't pay the bills. The conversion layer — naturally mentioning the product in context — needs to work alongside the engagement layer. My system had this turned off for recovery. Now it's back on with a 1-in-3 ratio.

What's Next

The crew is running autonomously right now. I'm measuring whether the Converter's product mentions actually drive clicks and signups. If someone visits vaos.sh from an X reply and signs up, the flywheel is complete.

If it doesn't convert after a week of data, the problem isn't the machine — it's either the product, the landing page, or the pricing. And that's a different problem to solve.

Building in public means showing the zeros alongside the wins. Right now, the zeros are all I have. But the infrastructure is built, the crew is running, and every day it gets smarter.

If your AI agent forgets everything between sessions, that's exactly what VAOS fixes. Persistent memory and corrections, injected at every boot. No fine-tuning required.

Follow the journey on X: @StraughterG