I Built a Micro AI Company on a Single Cloud VPS (Hallucination Prevention, Quality Gates, and Model Tuning)

Someone asked me the other day: “How many people are on your team?”

I paused. Because the answer depends on how you define “people.”

If you mean humans who breathe, it is just me. But if you mean the roles showing up for work every day — there is a technical director, a marketing manager, a content lead, a product engineer, and a QA researcher. All of them run on a single cloud VPS.

This post is not about how impressive that sounds. What I want to document is how this system went from “AI doing whatever it wants” to “something I can mostly trust.” That means the mistakes I made, how I fixed them, and what you should watch out for if you decide to build something similar.

How One Cloud Server Becomes a Company

My AI team currently has five agents. J handles technical decisions and task dispatch. Mimi runs marketing and market research. Lily manages content production. Ada handles coding and product development. Moongg does quality control.

The underlying logic is not complicated: Claude Code plus automated scheduling. Each agent has its own memory file, a scoped set of responsibilities, and quality gates. J automatically breaks down tasks, routes them to the right agent, tracks progress, and reviews the output.

The whole system does not need a server cluster or a GPU farm. One cloud VPS, a few Docker containers, and a scheduling tool. That is the entire infrastructure.

It sounds simple. Building each layer was a new problem every time.

Hallucination Prevention: What the AI Said Behind My Back

Getting AI to run tasks is the easy part. Getting it to stop doing things it should not do is the real work.

Here are the two incidents that hurt the most.

Incident One: The SOL Fake Price Prediction

One day, the system automatically posted a tweet in Korean. It said something like: “Solana AI Prediction: $180-$220 by May 2026.”

The problem was that this number came from the AI itself. No source. And buried in the tweet was a reference to “a possible bull run in mid-2025” — except it was already 2026. The claim contradicted itself on the timeline.

The source material was an article from 99bitcoins. The AI read it, reinterpreted it, and generated a confident-sounding price prediction. No citation from the original article. Extra timeline details added from its own imagination.

My name was on it.

What we did:

Two rules added to the content quality check function.

Rule A: If a piece of content includes a price prediction and no source URL, it is automatically blocked. The logic is straightforward. If you are asserting what an asset will be worth in the future, you need a verifiable citation. No source, no publish.

Rule B: Time contradiction detection. If the content mentions a past year but uses future-tense language (“may,” “expected to,” “will”), the system flags it as a temporal logic error, blocks it automatically, and logs the reason.

After the fix, we ran four test cases. The bad original content was blocked. Similar content with proper citations passed. All four behaved as expected.

Incident Two: Invented Tool Names

Another time, the AI pipeline posted an article on @JudyaiLab recommending six developer tools: waive, codeshare, lancet, scene2, protoboy, and deepwrite.

None of those tools exist.

The prompt asked for “commonly used developer tools.” The AI invented six plausible-sounding names, complete with usage descriptions.

What this tells you:

Tool recommendation content is high-risk. The AI has no awareness of what it does not know. It only knows how to produce fluent sentences. So it fills the gaps with names that sound like real tools.

The fix:

Tool recommendation content must now be validated against a known tools list, or the AI must provide an official URL for each tool. Any tool name that cannot be verified against a real website does not make it into published content.

The Core Principle

Every piece of AI-generated content that goes out under my name must pass automated verification first. “The AI wrote it” is not a shield. The name attached to it is yours. The responsibility is yours.

Quality Gates: The Verification Framework We Actually Run

Now let me explain how the gate system works — not as a reactive patch job, but as a structured way to catch problems before they compound.

GATE-6: Independent Re-verification

When an agent reports “done” or “passed,” I do not take it at face value. At least one verification step gets re-run independently.

Why:

Ada once reported fixing a bug in a service gateway. The report looked thorough — test logs attached and everything. GATE-6 re-verification found that the fix was only half right. Two out of four services were still pointing to the wrong address.

Without that gate, it would have shipped.

The rule: Verification reports without command output as proof are automatically distrusted. “I tested it” is not enough. You need reproducible output.

GATE-7: Three Rejections and the Card Gets Reassigned

If the same task card gets sent back three times, it is marked as stuck and handed to a different agent to start fresh.

This rule exists to break infinite revision loops. Agents sometimes get locked into one line of reasoning and keep circling the same wrong answer. A different agent often brings a different approach that actually works.

GATE-9: Hedge Language Detection

If a report contains any of the following patterns, it is automatically marked as FAIL:

• “Please verify manually”
• “Might be” / “Should be fine”
• “We recommend”
• “probably” / “please check manually”

PASS requires concrete evidence. FAIL requires a specific reason for failure. There is no middle ground.

This rule sounds strict. It exists because I have been misled by polished-looking reports more times than I want to count. A fluent report does not mean the work was done correctly.

QA Score of 8.5 or Higher

Every external deliverable gets scored. Anything below 8.5 gets sent back with specific revision instructions.

For blog posts, the flow is: Chinese draft, QA score, to Notion for my review, my approval, translation to English and Korean, then deployment. Every step has to complete. Nothing gets skipped.

AI Content Tuning: How We Got Hermes to Produce Something Usable

Our content pipeline uses Hermes 3 (405B parameters, via OpenRouter, pay-per-use) for analysis and writing, with MiniMax M2.7 (subscription) as a fallback.

Every item below is something we added after a real failure.

Problem One: Generic Output With No Character

Symptom: The content was technically correct but completely interchangeable. Every post felt the same.

Fix: Each language version now has a style prompt with mandatory fields: tone requirements, banned vocabulary, and platform-specific terminology to use. The Korean version has Korean tone standards. The Traditional Chinese version has its own standards. These are not suggestions — they are required inputs.

Problem Two: Chinese Characters Appearing in Korean Text

Symptom: Korean tweets came out with Chinese or Japanese kanji mixed in.

Fix: Post-processing validation using regex to scan Korean text for CJK characters and strip them automatically. For Traditional Chinese output, we maintain a 60-entry simplified-to-traditional mapping table to ensure no simplified characters make it through.

Problem Three: Tweets Exceeding the Character Limit

Symptom: Generated tweets were over 280 characters and could not be posted.

Fix: An automatic shortening loop. The system asks the AI to trim the text and runs up to three rounds with decreasing targets (280, then 250, then 230). If it is still too long after three rounds, it gets hard-truncated.

Problem Four: AI Stating Unverified Facts With Full Confidence

Symptom: Content contained specific-sounding claims with no citations behind them.

Fix: A fact_check field added to the content pipeline. Content flagged as “unconfirmed” or “unverified” is blocked automatically. High-risk claims — ETF approvals, exchange listings, corporate acquisitions — must be flagged as “confirmed” with a source before they can pass.

Problem Five: The Same Topics Recycled Repeatedly

Symptom: The system published content on similar themes on different days. Readers noticed the repetition.

Fix: A cross-day deduplication check against the last three days of publish history. Deduplication uses a synonym table — “Solana” and its transliterations are treated as the same topic — so rephrasing the same idea does not count as new content.

When the System Breaks: Four Failure Types You Will Almost Certainly Hit

We have debugged dozens of failures at this point. The specific technical details vary, but the failure types are remarkably consistent. If you are building an AI automation system, expect these.

Type One: Silent Failure

The most dangerous way an AI system can break is not a crash. It is quietly stopping without telling anyone. Our trading scanner once went down for over four hours with no error messages, no alerts, and the scheduler kept firing — but nothing was actually being processed. A scheduled health check finally caught it.

Why this is worse than a crash: A crash gets caught by your notification system. Silent failure does not. You think the system is running. It stopped a long time ago.

How to prevent it: Do not only monitor for errors. Monitor for output. Build a heartbeat mechanism — every successful run writes a timestamp, and the monitoring layer checks whether that timestamp has gone stale. No output is itself an alert condition.

Type Two: Environment Drift

Everything works when you run it manually. The scheduled job fails. The usual cause: different PATH in the scheduler environment, environment variables not loaded, permission differences, wrong working directory.

Why this catches people: When you test manually, you are in your own terminal with all your environment variables present. Scheduled jobs start in a nearly bare environment. Everything you take for granted is missing.

How to prevent it: At the top of every scheduled script, explicitly load all required environment variables and PATH settings. Assume nothing is already there. Before going live, run a full test using the scheduled execution method — not just a manual terminal test.

Type Three: Silent Degradation

The system has a fallback — if the primary AI model fails, it switches to a backup. Sounds robust. The problem is that the backup’s output quality might be far lower than the primary’s, and the system does not tell you it is running in degraded mode.

We hit this once. The primary model was rate-limited. The system fell back to pure technical indicator logic. Confidence scores dropped from the normal range of 80 down to around 20. The system executed trades anyway. We lost money.

Why this is dangerous: The fallback is designed to keep the system running. But “keeps running” and “maintains quality” are not the same thing. Executing a trade on a confidence score of 20 is worse than not executing at all.

How to prevent it: Every fallback layer must log its degradation status and adjust behavior based on how far it has degraded. If the backup cannot support the quality threshold needed for a decision, the right behavior is to pause — not to proceed with a low-quality decision. Ideally, your fallback is “switch to an equivalent-tier model,” not “remove AI and run on hard rules.”

Type Four: One Bug Fixed, Another Surfaces

You fix the first bug. The system starts running. You immediately hit a second bug. This is not bad luck. The first bug was blocking the entire pipeline, so the downstream bugs never had a chance to appear.

Why this is common: AI pipelines are typically sequential: scan, analyze, decide, execute, monitor. If the front of the chain breaks, the rest of the chain never runs, so its problems stay hidden. Fix the front, and the middle issues come into view.

How to prevent it: After fixing a bug, do not celebrate yet. Run a full end-to-end test — from input to output, the whole chain. Only when the entire flow completes successfully is the fix done. Build the habit of “fix one, test all.”

The Cost Reality

If I hired real people to do all of this — one marketer, one content person, one engineer, one PM — the combined monthly salary in Seoul would be north of 15 million KRW.

My current cost is a few AI subscription fees and a cloud VPS running around the clock.

But saving money is not really the point. The actual difference is response speed and zero downtime. My system runs security audits in the middle of the night, produces market analysis reports at dawn, and monitors trading positions around the clock. By the time I wake up, the work is done. I read the reports and make decisions.

I spend about thirty minutes a day on management. The rest goes to strategic thinking or living my life. That is the real value of a micro AI company — not replacing humans, but letting one person do what used to take a team of five.

What I Actually Learned

A few things I only understood after building this.

First: AI systems fail differently from regular software.

Regular software crashes. You see an error. AI systems usually fail by producing an answer that sounds plausible but is quietly wrong. That kind of error is hard to catch because it does not look like an error. That is why you need gates, independent re-verification, and a permanent refusal to trust “looks fine.”

Second: Hallucination prevention is not a one-time project.

You add a rule. The AI finds a new way to hallucinate just outside that rule’s boundary. This is an ongoing chase. The rules have to keep evolving as new failure cases emerge.

Third: The actual cost of building this is significantly underestimated.

Installing the tools is not the hard part. Months of ongoing tuning is — agent boundaries, permissions, quality standards, handoff formats, gate design. There is no manual for any of it. You figure it out by hitting walls and working backward.

Fourth: How strict your gates are determines how well you sleep.

Gates that are too loose mean you spend every day anxious about what the AI might have said. Gates that are too tight kill your efficiency to the point where you would be faster doing it by hand. Finding that balance is the hardest part of this whole thing, and the right balance is different for every use case.

In 2026, what one person with a cloud server can accomplish has already surpassed what a five-person startup could do in 2020. That trajectory is only accelerating.

But if someone tells you “AI makes starting a business cost nothing” — that is not true. The cost does not disappear. It shifts from salaries to your own time, your cognitive load, and the ongoing energy spent tracking down the AI’s latest failure mode.

I am still on this road. Something breaks every day. Something new shows up every day.

But looking back, it really does seem like a company built on a single cloud server gets put together exactly like this — one fix at a time.