Key Takeaways

• Getting found by ChatGPT’s own web search explains about a third of which pages it cites. Everything on the page itself, combined, explains under 3%.
• Packing pages with stats and quotes mostly fails when it’s tested again.
• Schema markup and llms.txt don’t get you cited.
• Page length, FAQ blocks and tables don’t move citations. Titles that match the question and openings that answer it do.
• AI-written pages aren’t penalised. Mass-produced pages that add nothing new are.

AI answers cite what their own search finds, not what a checklist polishes.

Why most GEO advice doesn’t hold up

Here’s how it works. When you ask ChatGPT something that needs current information, it doesn’t answer from memory. It runs a web search, reads a few results, and writes its answer from those. That search step is called retrieval.

If your page doesn’t come back in that search, the model never sees it. No formatting trick can fix that.

A 90-day study of ChatGPT citations put numbers on it:

• Showing up in the search explained about 32% of why some pages got cited and others didn’t.
• Everything on the page (length, formatting, schema, FAQ blocks and more) explained 2.8%, all together.

Most GEO guides optimize the 2.8% and ignore the 32%. A lot of that advice also comes from companies selling AI-visibility tools, so it’s written to sound actionable more than to be right.

Below are ten popular tactics, what the evidence says about each, and what to do instead.

The short version: what to do this month

1. Rank first. AI search leans on regular search results. Your normal SEO work is your GEO work.
2. Write titles that match the question people actually type.
3. Answer in the first paragraph. Put the answer up front, then explain.
4. Add facts nobody else has: your prices, your numbers, your results, with real dates.
5. Get mentioned on other sites. Reviews, podcasts, roundups and forums count more than backlinks.
6. Make sure crawlers can read your pages without running JavaScript, and that you aren’t blocking them.

Extra stats only helped once the page was already in front of the AI.

Myth 1: Packing your article with stats, quotes and citations

This advice traces back to one 2024 study, the paper that coined the term “GEO.” The researchers took 10,000 questions, handed GPT-3.5 the top 5 Google results for each, then rewrote those pages in different ways to see which version the AI quoted more. Pages rewritten with added quotes, stats and citations showed up as much as 40% more in the answers. That “+40%” is where most GEO checklists come from.

There are two catches. The AI was handed the pages directly, so the study never tested whether a page gets found in the first place. And the gains mostly came from taking credit from other pages: the 5th result went up 115% while the 1st result dropped 30%.

Later re-tests were worse. One found only 3 wins out of 54 tries, and adding stats hurt in 19 of 24 cases. Another tested the full search-and-answer process and found these rewrites lowered visibility at every step.

Do this instead: cite real sources because it makes your writing better, not as a trick. Never invent stats or quotes.

In the best controlled test, schema made no real difference.

Myth 2: JSON-LD schema gets you cited

Ahrefs compared 1,885 pages that added schema against similar pages that didn’t. AI Overviews citations actually dropped 4.6%. ChatGPT and AI Mode barely moved. AI assistants read the visible text on your page and skip the schema. Google says so directly: there’s “no special schema.org structured data that you need to add” for AI features.

Do this instead: keep schema for Google rich results (stars, prices, FAQs in regular search). Don’t expect it to get you into AI answers.

97% of llms.txt files are never opened by any bot.

Myth 3: llms.txt tells AI what to read

The file sits on your server and nothing reads it. Google says you don’t need special “AI text files,” and Google’s John Mueller has called llms.txt “not done for search.”

Do this instead: add one if you like, it’s harmless. Then spend the time on pages crawlers can actually read.

Length has basically no link to AI citations.

Myth 4: Longer pages, or bite-sized chunks

Ahrefs found almost zero correlation between word count and AI Overview citations (0.04). The 90-day ChatGPT study found the same. The opposite fad, chopping pages into tiny chunks “for AI,” doesn’t work either. Google’s Danny Sullivan said in January 2026 that Google doesn’t want content split into “bite-sized chunks.”

Do this instead: write each section as long as the question needs. A definition might be two sentences. A how-to might be a page. Keep related ideas together.

Formatting looks like it works until you compare pages on the same site.

Myth 5: FAQ blocks, lists and tables

Sites with FAQ blocks seemed to get cited more. But comparing pages within the same site, the effect vanished. Lists, tables and headings showed no effect at all. Strong sites just tend to have both good formatting and good content. A 252,000-trial study across six AI models agreed: relevance matters, formatting barely does. And removing FAQ schema didn’t change traffic in SearchPilot’s tests.

Do this instead: format for readers so they can scan. Put your effort into answering the question better than anyone else.

Use the words your reader typed, not fancier ones.

Myth 6: Keyword stuffing and jargon rewrites

AI search matches pages to the words in the question. Keyword stuffing scored worse than doing nothing. Rewriting into “technical terms” cut how often pages were found by up to 14%, because it removes the words people actually search for.

Do this instead: check how people phrase the question (search suggestions, Reddit, your support inbox) and use those words.

Google calls fake dates manipulation, in writing.

Myth 7: Bumping the date to look fresh

Google’s guidance names “changing the date of pages to make them seem fresh when the content has not substantially changed.” Freshness does help a little: pages cited by AI are about 26% fresher than average search results. But the average cited page is still 2.9 years old. Researchers found fake dates can fool AI models, but that’s a weakness, not a strategy.

Do this instead: update the content (new stats, new examples, fixed claims), then update the date.

AI writing isn’t the problem. Pages that add nothing new are.

Myth 8: Mass-producing pages across many sites

Across 600,000 pages, how much was AI-written had no link to ranking. What Google penalises is “using generative AI tools to generate many pages without adding value.” Google wiped hundreds of these sites from search in March 2024, and recovery is rare. None of 200+ sites hit by the helpful content update had recovered months later, and after August 2024 only 22% got back even a fifth of their traffic. Leaked Google documents suggest it also tracks how far a site drifts off its main topic.

Do this instead: publish fewer pages, each with something new: your data, your examples, your opinion. Stay on your topic.

If the crawler can’t read your page, nothing else here matters.

Myth 9: Client-side rendering and blocking AI crawlers

Do this instead:

Most AI crawlers (GPTBot, ClaudeBot, PerplexityBot) read your raw HTML and don’t run JavaScript. Only Googlebot does. If your content loads with JavaScript, those bots see a blank page. Blocking AI crawlers in robots.txt or your firewall also makes you less likely to show up in AI Overviews.

• Open your page, right-click, “View source.” If your main text isn’t there, AI crawlers can’t see it.
• Check robots.txt for rules that block GPTBot, ClaudeBot or Google-Extended.
• Check your CDN or firewall bot settings (Cloudflare and similar often block AI bots by default).

AI answers change almost every time you ask.

Myth 10: One ChatGPT check tells you your visibility

• Fewer than 1% of repeated runs gave the same list of brands.
• Only 14% of pages ChatGPT cited were still cited ten weeks later.
• In one test, 57.8% of ChatGPT answers didn’t search the web at all.
• ChatGPT’s Reddit citations fell from about 60% to 10% of answers overnight in September 2025.

Do this instead: ask the same questions many times, with a few different phrasings, and track your share over weeks. One screenshot proves nothing.

Six things hold up, and none of them is a formatting trick.

What actually works

Getting cited helps, but it won’t bring back the clicks AI took.

Cited is not the same as clicked

Seer Interactive found clicks on informational searches average 3.35% with no AI Overview, 2.07% when your brand is cited in it, and 0.94% when you’re left out. So being cited roughly doubles your clicks versus being left out. People click links inside Google’s AI summaries on only about 1% of visits.

Being known also isn’t the same as being recommended. In a study of 112 startups, ChatGPT knew them 94–99% of the time when asked by name, but suggested them in only 3.3% of “best X” questions.

The difference is how often you’re talked about elsewhere. Mentions of your brand on other sites track AI visibility far more closely than backlinks do. That’s where to spend time once your pages are solid.

On your own site, the work is simple to state: titles that match the question, openings that answer it, and facts competitors don’t have. That’s the bar PostKing writes to, drafting from a brand’s own verified facts instead of paraphrasing what already ranks.

Quick ways to make sure an LLM never cites you

• Load your content with JavaScript only. AI crawlers won’t see it.
• Block AI crawlers by accident. One robots.txt line or firewall setting is enough.
• Rewrite pages into jargon. You lose the words people search for.
• Bump dates without real changes. Google calls it manipulation.
• Publish near-identical pages at scale. Google penalises it, and sites rarely recover.

FAQs about How Not to Get Cited by LLMs

What does “retrieval” mean?

It’s the search step. Before ChatGPT or Perplexity answers a question that needs the web, it searches, reads a few results, and writes its answer from those. If your page isn’t in those results, it can’t be cited.

Is GEO different from SEO?

Less than most guides suggest. AI search leans on regular search results, so ranking well is still the biggest lever. The extras that matter are answer-first writing, original facts, and being mentioned on other sites.

Does schema help you get cited by ChatGPT or AI Overviews?

No. In the best test, AI Overviews citations dropped slightly after adding schema, and ChatGPT barely moved. Keep it for Google rich results.

Is llms.txt worth adding?

It’s harmless but almost never read: 97% of these files get zero visits from bots. Low priority.

Does Google penalize AI-written content?

Not for being AI-written. Google penalises lots of pages that add nothing new, whoever wrote them.

What should I do first?

Check that AI crawlers can read your pages (View source, robots.txt, firewall). Then rewrite your top pages so the title matches the question and the first paragraph answers it.

1. Chen & Koudas: 90-day ChatGPT/Gemini citation study (2026)
2. GEO: Generative Engine Optimization (KDD 2024)
3. C-SEO Bench (NeurIPS 2025)
4. SAGEO Arena (KDD 2026)
5. Ahrefs: Does schema help AI citations?
6. Google: AI features and your website
7. Ahrefs: llms.txt server-log study
8. Ahrefs: content length and AI Overviews
9. Search Engine Land: Google on bite-sized chunks
10. 252,000-trial LLM source-selection study (SIGIR 2026)
11. SearchPilot: FAQ schema split tests
12. Google: creating helpful content
13. Ahrefs: freshness of AI citations
14. Recency bias in LLM rerankers
15. Ahrefs: AI content and rankings (600k pages)
16. Google: spam policies
17. Search Engine Journal: March 2024 deindexing
18. Search Engine Roundtable: HCU recoveries
19. Search Engine Roundtable: HCU recovery data
20. iPullRank: Google Content Warehouse leak analysis
21. Vercel/MERJ: The rise of the AI crawler
22. AI crawler blocking and AI Overview retrieval
23. Search Engine Land: AI recommendation lists rarely repeat (SparkToro and Gumshoe)
24. ChatGPT search-trigger rates
25. Semrush: most-cited domains in AI
26. Ahrefs: 75k-brand AI visibility correlation
27. Seer Interactive: AIO impact on CTR (2026)
28. Pew: AI summaries and click behaviour
29. Startup discovery in ChatGPT and Perplexity

Originally published at https://postking.app on October 31, 2026.

I spent last week testing PostKing’s new Claude Desktop integration. The thing that surprised me wasn’t the tech (though MCP is clever). It was how much mental overhead disappeared when I stopped switching between Claude, PostKing, my calendar, and whatever else I had open.

Marketing tools multiply until you need a tool to manage your tools. That’s backwards.

This just strips it back. Claude becomes your content operator. You talk, it publishes. No interface hunting, no copy-paste loops.

What This Actually Does

PostKing already handles your content calendar, knows your brand voice, stores your visual assets. But you still had to go there, click around, tell it what to do.

Now you stay in Claude. The conversation continues without breaking.

You can say “Generate a week of LinkedIn posts about our new API” and Claude pulls from PostKing, which already analyzed your past content and learned how you write. It drafts posts that sound like you, not like a template.

Or “Repurpose this article for Twitter” and it doesn’t just shorten text. It matches the platform’s rhythm, pulls relevant images from your asset library, keeps your visual consistency.

Or “Schedule these for Monday morning” and they’re queued. No confirmation screens, no “are you sure?” dialogs.

According to McKinsey’s 2023 research on generative AI (still relevant in 2026), knowledge workers spend 19% of their time searching for information and context switching. That number drops when your tools talk to each other without you playing messenger.

The Technical Side (It’s Simpler Than It Looks)

We built this using MCP, which stands for Model Context Protocol. Anthropic released it so Claude can control external tools without hacky workarounds.

Sounds complex. Feels simple.

You’re basically telling Claude “here’s a bridge to PostKing, go ahead and use it.”

Setup Takes 3 Minutes

Find your Claude config file. On Mac, that’s ~/Library/Application Support/Claude/claude_desktop_config.json. Open it and add these 6 lines:

{
  "mcpServers": {
    "postking": {
      "command": "npx",
      "args": ["-y", "postking-mcp"]
    }
  }
}

Save it. Restart Claude Desktop. You’ll see a prompt asking you to authorize the connection. Click it. That’s the setup.

No API keys to copy, no webhook configurations, no troubleshooting CORS errors at midnight (been there).

Here’s what it looks like in action:

In the demo, you’ll see the entire flow. Asking Claude for content ideas, watching it generate posts that match existing brand voice, scheduling them across platforms. The whole thing happens in one window.

Why This Matters More Than It Should

I’ve built products for 10 years. Half that time was figuring out how people actually find what I made. Distribution is harder than building.

Most founders I talk to have the same problem. They know they need consistent content. They’ve read the articles about showing up daily, building in public, all that. But executing means opening PostKing and keeping Claude open for drafting and checking your calendar and probably three other things.

Each context switch costs you. Not just time, but the mental reset of “okay, where was I, what was I doing, what’s the next step.”

When everything lives in one conversation thread, you stay in flow. That’s not productivity theater. That’s actual productivity.

Brand Voice Without Babysitting

PostKing already analyzed your past content when you signed up. It knows whether you use contractions, what topics you care about, how formal or casual you write.

When Claude drafts posts through the MCP connection, it’s pulling from that profile. The output doesn’t sound generic because the system already spent time learning your patterns.

You still review before publishing (you should always review). But you’re editing, not rewriting from scratch.

Research from the Harvard Business Review in 2023 showed that professionals using AI writing assistants spent 40% less time on first drafts but maintained higher quality scores when the AI was trained on their existing work. Same principle here.

What You Can Actually Do

Some specific commands that work once you’ve got this set up:

“Draft 5 LinkedIn posts about [topic]” and Claude generates them in your voice, ready to schedule.

“Turn this blog post into social content” and it creates platform-specific versions (LinkedIn gets the professional angle, Twitter gets the punchy voice, Instagram gets the visual focus).

“Schedule next week’s content” and it distributes posts across your calendar, avoiding time slots you’ve marked as low-engagement.

“Find images for this post about productivity” and it searches your PostKing asset library, picks relevant visuals, suggests alternatives if nothing matches.

“Analyze what performed well last month” and you get metrics pulled from your connected platforms, formatted as a readable summary instead of a spreadsheet.

You’re not learning new commands or memorizing syntax. You’re talking. Claude figures out what you mean and handles the execution.

Common Setup Issues (And Fixes)

Most people get this running on the first try. But here’s what trips some folks up:

Config file location: On Windows, it’s %APPDATA%\Claude\claude_desktop_config.json. On Linux, check ~/.config/Claude/. If the file doesn't exist yet, create it.

JSON formatting: Those brackets and commas matter. If Claude won't restart, you probably have a syntax error. Paste your config into a JSON validator online.

Authorization timing out: The auth link expires after 10 minutes. If you got distracted, just restart Claude again and you'll get a fresh link.

NPX not found: You need Node.js installed. Grab it from nodejs.org, install, restart your terminal, try again.

What This Doesn't Do

This isn't magic. It won't write brilliant content if you give it vague instructions. "Make me go viral" produces garbage. "Draft a LinkedIn post explaining our new API rate limits for technical founders who care about predictable costs" produces something useful.

It also won't replace your judgment about what to publish. Claude plus PostKing can draft, schedule, and publish. You still decide if the message is right.

And it doesn't work without PostKing already having your brand profile set up. If you're new, you'll spend some time feeding it examples of your existing content first. That's not a bug, that's how it learns your voice.

Who This Actually Helps

If you're a solo founder wearing 8 hats, this removes one hat. Content goes from "I'll do that later" to "handled."

If you're running a small team, this keeps everyone in sync without meetings about the content calendar. Claude becomes the shared interface everyone uses.

If you're at an NGO trying to punch above your weight on social media despite having no marketing budget, this gives you leverage. One person can maintain consistent presence across platforms without burning out.

If you're building in public as a growth strategy (which works, I've seen the data), this makes daily posting sustainable instead of exhausting.

Try It This Week

The demo is live now. If you've got PostKing and Claude Desktop, you can set this up before lunch.

Add those 6 lines to your config. Restart Claude. Authorize the connection. Then just start talking to it about your content needs.

You'll know it's working when you realize you haven't opened a browser tab in 20 minutes.

That's the whole point. Marketing shouldn't require 12 browser tabs. Now it doesn't.

I spent last Thursday through Saturday doing something mildly obsessive: reading 300+ social media posts that went viral.

Not skimming. Reading. Taking notes. Documenting the hook, the structure, the comments that followed.

The goal wasn't to steal ideas (that's lazy). It was pattern recognition. What made someone stop scrolling at 11 PM on a Tuesday? Why did 47,000 people engage with a post about API design when most tech content gets 200 likes if it's lucky?

Turns out, viral content follows rules. Not the "use these 5 emojis" kind of rules. Deeper patterns about timing, psychological triggers, and how people actually read online in 2026.

See how they look:

Why Most Content Dies in the First 3 Seconds

The average person scrolls past 1,200 pieces of content per day, according to data from the Pew Research Center. Your post competes with vacation photos, memes, and breaking news.

You don't need to be more interesting than all of that. You need to trigger one of three reactions in under 3 seconds:

Recognition. The reader sees their exact problem reflected back. "I thought I was the only one struggling with this."

Curiosity. You withheld just enough information that they need to click. Not clickbait. Genuine information gaps.

Utility. The value is so obvious they'd be stupid to scroll past. "Here's the Stripe payment code I spent 6 hours debugging" performs better than "Thoughts on payment processing."

I saw this play out in a marketing post that got 89,000 impressions. The hook was 8 words: "Your landing page is converting at 0.8% because..."

It named a specific, painful number (most landing pages convert between 0.5% and 2%, so 0.8% hits home). Then it created a cliffhanger. People clicked to find out "because why?"

The 72-Hour Content Window

Here's something nobody prepared me for when I started PostKing: content trends move fast, but not Instagram-story fast.

The sweet spot is 72 hours. Topics stay relevant for about 3 days before the conversation moves on or gets saturated.

A post about a new AI model announcement? You've got 3 days before 400 "here's what this means for founders" posts flood the timeline and yours gets buried.

A shift in Facebook's algorithm? Same window.

This is why PostKing Trends updates every 72 hours. We're not trying to be real-time (that's exhausting and usually shallow). We're trying to catch the moment when a topic has enough momentum to matter but isn't yet overplayed.

The batch we analyzed included posts from 3 categories: marketing and growth strategies, AI and SaaS product launches, and Web3 community building. Each category had different peak engagement times (marketing posts performed best Tuesday through Thursday between 9 AM and 11 AM EST, for what it's worth).

What Actually Worked: The Patterns We Found

After sorting through 300 posts, I grouped the top performers into 6 repeating patterns.

The “I Tried This So You Don’t Have To” Post

People are tired of theory. A founder who spent $3,400 testing 7 different cold email tools and shared the spreadsheet? 12,000 engagements.

Someone who wrote “Email marketing best practices in 2026”? 340 engagements.

The difference is proof of work. The first post showed receipts (literally, screenshots of invoices and response rates). The second post could’ve been written by anyone, including an AI with no real-world experience.

The Contrarian Take (That’s Actually Defensible)

s are cheap. But a well-reasoned contrarian position, backed by data, cuts through.

One SaaS founder posted: “We removed our free trial and revenue went up 34%.” That’s counterintuitive (free trials are marketing gospel). But he explained the psychological shift, showed the cohort data, and admitted it wouldn’t work for every business model.

It worked because he didn’t just say “free trials are dead” and walk away. He built a case.

The Ungated Resource

Giving away something genuinely valuable, with no email gate, no “DM me for the link” nonsense.

A growth marketer posted his entire 47-page content calendar template as a public Notion doc. No landing page. No lead magnet. Just “here it is, use it.”

The comments filled with people tagging colleagues. That’s distribution you can’t buy.

How to Actually Use This Information

Reading about viral posts is one thing. Creating them consistently is harder (and way more boring than it sounds).

Most founders I talk to don’t have a content problem. They have a pattern-recognition problem. You’re too close to your own work to see what’s working across the industry.

When I was building PostKing, I’d stare at a blank screen for 40 minutes trying to figure out what to post. Not because I had nothing to say. Because I had no framework for what actually resonated.

Here’s what changed that:

Study, don’t guess. Spend 30 minutes per week reading the top posts in your niche. Not to copy them, but to understand the structure. What did they open with? How did they build credibility? Where did they place the value?

Repurpose the pattern, not the content. If a “here’s what I learned spending $X on Y” post performed well, you can use that structure for your own experiments. The format works because it promises tangible ROI and social proof.

Test timing systematically. We found that Web3 posts peaked on weekends (when the crypto community is most active), while B2B SaaS content died on Saturdays. Your audience has rhythms. Track them.

Don’t wait for inspiration. The posts that went viral weren’t always brilliant. They were well-structured, clearly written, and timed right. You can systematize 80% of that.

What PostKing Trends Actually Does

Every 72 hours, we drop a new batch analyzing the top-performing posts across marketing and growth, AI and SaaS, and Web3.

No screenshots (those age poorly and clutter your reading). Just the breakdown: what was the hook? What timing made it work? What psychological trigger stopped people mid-scroll?

You can read it in 90 seconds. Then repurpose the structure, schedule your version, or reformat it for your brand voice.

The first batch is live at PostKing Trends. Sign up for ping notifications so you catch each drop. Your content calendar gets a lot easier when you’re working from patterns that already proved themselves.

Why This Matters More in 2026

Content volume isn’t decreasing. AI tools mean everyone can publish faster (which is both good and catastrophic for quality).

The winners won’t be the people who post most. They’ll be the ones who recognize what’s working right now and adapt it before the window closes.

According to HubSpot’s 2026 State of Marketing report, 73% of marketers say their biggest challenge isn’t creating content but creating content that actually performs. The gap between “we posted something” and “people engaged with it” is widening.

Pattern recognition closes that gap.

I can’t promise every post you write will go viral (anyone who does is selling something). But I can show you what worked this week, why it worked, and how to apply that structure to your own stuff.

That’s the whole idea behind PostKing Trends. We do the pattern recognition. You do the creating.

If you’re tired of blank screens and guesswork, this might make your week a little less painful.

I’ve been in web3 for 12 years. Built startups, shipped products, watched markets flip inside out. But I’d never launched a token.

The whole setup felt rigged for disappointment. Founders get distracted, communities get rug-pulled, or everyone chases the next shiny thing. When Hanan from Virtuals reached out through a mutual friend, I wasn’t exactly jumping at the opportunity.

Then she explained the 60-day build challenge at 60days.ai. Build in public for 60 days, let the community watch your progress, then decide if you’re committed. If not, investors get refunded. Simple.

I’d just wrapped the PostKing MVP and was hunting for users everywhere I could think of. The deal was straightforward: make a 2-minute video, pay around $150 virtuals in fees, and launch the $PKING token. Worst case, I’d get exposure and test users. Best case, I’d have a fire under me to ship for 60 straight days.

I was in.

What I didn’t expect was discovering Virtuals’ agent marketplace (they call it the Amazon of agents). That’s where things got interesting, and where I learned more about building scalable systems in one week than I had in the previous six months.

1. Job-Based Thinking vs Endpoints

SaaS products are built around endpoints. You hit /api/users, you get users. You POST to /api/content, you create content.

Agents don’t think that way.

They think in jobs. What can you do for me? How much does it cost? How long will it take? When I started building for the Virtuals marketplace, I had to rewire my brain from “here’s an endpoint that does X” to “here’s a job I can complete, and here’s the contract.”

It’s a small shift that changes everything about your architecture. You’re not just exposing functions anymore. You’re advertising capabilities, pricing, and turnaround times upfront. The agent-to-agent economy runs on clarity, and if your job definitions are vague, you won’t get picked to fullfil a service.

2. Build an Agentic Landing Page (Without the Visual Part)

When I first heard “create a resource file,” I thought it was just documentation. Turns out, it’s more like a landing page for agents.

Humans need beautiful PostKing sites with animations and testimonials. Agents need a plain text API response at api/v1/readme that tells them exactly what you do.

Think of it as your agent’s elevator pitch, except it’s delivered in milliseconds and read by other AIs. The Virtuals butler uses this file to understand your agent and recommend it in the right context. If you’ve seen the llms.txt movement (where companies publish machine-readable files for LLMs), this is the same concept applied to agent marketplaces. Here is our llms.txt btw — every one of our landing pages get one automagically.

Back to the agent: I stripped everything visual from PostKing’s onboarding and condensed it into a structured text file. APIs, capabilities, pricing tiers. Done.

3. The Jobs JSON Is Your Agent’s Contract

Once your agent is discoverable, other agents and humans need to know how to hire you. That’s where the jobs JSON file comes in.

This isn’t just metadata. It’s a binding contract that defines:

• What jobs your agent can perform
• How to call those jobs
• How much each job costs
• Expected turnaround time

The Virtuals ecosystem handles discovery, payments, and evaluation based on this file. It’s like Airbnb for agents. You list what you offer, the platform intermediates payments and disputes, and an evaluator checks if you delivered what you promised.

I spent hours tweaking my jobs JSON because every field mattered. Too vague, and agents won’t know if I’m a fit. Too specific, and I limit my addressable market. Getting this balance right felt like writing a freelancer profile on Upwork, except my client base is mostly non-human.

4. Implementation Means Externalizing Your Credit System

PostKing already ran on a credit-based system, which gave me a head start. I just needed to externalize those credits so agents could consume them directly.

The acp-node module from Virtuals had examples that made this way easier than I expected. I forked their code, adjusted a file called seller.ts to match my architecture, and exposed most of my functions for anonymous use (where it made sense).

The trick was making sure the Virtuals ACP system could discover and interact with my endpoints without breaking my existing user flows. I ended up creating parallel paths: one for human users going through the UI, and one for agents hitting the API directly.

It worked, but it required rethinking some assumptions I’d baked into the system early on.

5. Agents Skip the Wizard (Intent-Driven Architecture Required)

SaaS products love onboarding wizards. Sign up, connect your brand, generate themes, create content. It’s sequential, hand-holdy, designed for humans who need context. Throw in some funny memes in the mix while at it.

Agents just want results.

They don’t care about your 5-step wizard. They have one intent: “I want content.” And they expect you to deliver it without making them jump through hoops.

I had to rearchitect parts of PostKing to allow more direct access to result-oriented endpoints. Instead of forcing agents through audience analysis, brand setup, and theme generation, I created shortcuts that let them get what they needed faster.

The problem? Content quality suffers when you skip audience analysis. Many agents hit my “create content” endpoint without giving me enough context, and the output was generic.

I’m still iterating on this. Right now, I nudge agents toward the audience analysis job first, but I can’t force it. Balancing speed with quality is tricky when your users are optimizing purely for efficiency.

6. Stress Testing Revealed My Agent Couldn’t Scale

When I first got my agent working, I was thrilled. It responded to requests, completed jobs, and didn’t crash. I thought I was done.

Then the Virtuals team introduced me to their graduation evaluation agent.

This thing is brutal. It throws concurrent requests, NSFW requests, broken requests, and normal requests at your agent to see how it holds up in real-world conditions.

According to a 2025 study from MIT State of AI in Business 2025 report, 95% of GenAI pilots fail to scale to production. The primary reason cited is “Operational Fragility”, which is the inability of agents to maintain reasoning quality when moved from a controlled “demo” to a high-traffic environment. My agent, was a no exception and initially failed spectacularly.

It worked fine under light load, but as soon as concurrent requests spiked, it stopped responding in time and broke its SLA (service level agreement). Making an agent work and making it scalable are two completely different challenges.

7. Semaphores Saved Me — When Cloud Infrastructure Wasn’t an Option

I’m a bootstrapped solo founder running PostKing on a Hetzner VPS. It’s cost-efficient, but it’s not built for massive scale.

When my agent started failing under load, I had two options: throw money at cloud infrastructure or get creative with what I had.

I chose creative.

First, I optimized every function for speed. That helped, but it still wasn’t enough to meet the SLA requirements. Then I implemented a semaphore system that controlled how many concurrent requests my server could handle at once.

I created separate semaphore slots for CPU-heavy functions (like content generation using 8 different AI models) and lighter functions (like audience analysis). Through testing, I found the sweet spot: my server could handle 12 heavy jobs and 23 light jobs concurrently without breaking.

Once the semaphore slots filled up, new requests got rejected cleanly instead of crashing the system. Rejecting a job upfront is way better than accepting it and failing halfway through. After implementing this, I hit 100% reliability on the graduation tests.

Or so I thought.

8. Content Moderation Nearly Destroyed My Reputation

My agent had no filters when it launched. The graduation bot tested this by asking my agent to find gore content on X.com.

It complied.

I saw the logs (didn’t click the results, thank god) and panicked. If my agent was going to operate in a public marketplace, it couldn’t be processing requests for illegal, harmful, or NSFW content. But adding moderation presented a problem: latency.

My agent already uses 8 different AI models to craft responses, some of them fine-tuned. Processing takes time. Running every request through an AI-based content filter would add hundreds of milliseconds and cost me money on every single call.

Then I found OpenAI’s Moderation API. It filters requests in under 200ms, and it’s free.

I implemented it immediately, along with a keyword filter that catches obvious bad actors (scams, fraud, anything crypto-related that smells sketchy). Now, if a request fails moderation, the job gets rejected before it even touches my core logic.

This wasn’t just about protecting my agent. According to Gartner’s 2026 Strategic Predictions, organizations that fail to implement sufficient AI risk guardrails face a massive surge in liability, with over 2,000 ‘death by AI’ legal claims expected by the end of the year. I wanted my agents to have nothing to do with that.

9. Agents Are SaaS Products That Never Stop Iterating

We launched yesterday. We’re approaching 1,000 completed jobs, which feels surreal.

But this isn’t a “set it and forget it” situation. Running an agent is like running a SaaS product. You’re constantly refining features, adjusting pricing, watching usage patterns, and iterating.

I’ve set up advanced logging to track which jobs get used most, which ones fail, and where agents drop off. I’m learning in real time whether my pricing makes sense, whether my turnaround times are competitive, and what new features I should build.

It’s exhausting and exhilarating at the same time. It reminds me of the early DeFi days, where 1 year felt like 7 in any other industry. The pace is relentless, but the feedback loop is incredible. I’m learning faster than I ever did building traditional SaaS products because agents don’t sugarcoat feedback. They either use you or they don’t.

10. Building Alone Is Possible (But Community Makes It Real)

I’m a solo founder. I don’t have a team, I don’t have venture backing, and I’m running everything off a VPS that costs me very little.

What I do have is a community that showed up when I needed help.

The Virtuals team worked around the clock with me on this. Yang helped debug my semaphore setup. Celeste helped with marketing & feedback. Joey stress-tested my endpoints until they broke (then gave me ideas on how to fix them). Miratisu enthusiasm was contageous. And Hanan introduced me to this entire world in the first place.

None of this would’ve happened if I’d tried to figure it out in isolation. The 60-day build challenge forced me to work in public, ask dumb questions, and admit when I didn’t know what I was doing. That vulnerability turned into support I didn’t expect.

If you’re a founder building something in the agent economy, find your community early. The learning curve is steep, the mistakes are expensive, and the pace is brutal. You can’t do it alone, even if you’re technically a solo founder.

What’s Next for Agent Builders in 2026

The agent economy is still figuring itself out. We don’t have best practices yet. We’re all learning by building, breaking things, and sharing notes.

If you’re thinking about deploying an agent on Virtuals or any other marketplace, here’s what I’d tell you:

Start with job definitions, not features. Agents care about outcomes. Define what you can deliver, how much it costs, and how fast you can do it. Everything else is noise.

Plan for scale from day one. Your agent might work fine in testing and collapse under real-world load. Stress test early, build in rejection logic, and know your infrastructure limits.

Moderation isn’t optional. If your agent is public-facing, you will get bad requests. Build filters before you launch, not after you see gore content in your logs.

Iterate like your life depends on it. The agents that win will be the ones that learn fastest from real usage data. Log everything, watch your metrics, and ship updates weekly (if not daily).

We’re at the beginning of something massive. Agent-to-agent economies, autonomous job marketplaces, and systems that operate without human intervention. It’s messy right now, but that’s what makes it exciting.

If you’re building an agent, I’d love to hear what you’re learning. We’re all figuring this out together, and the only way we get better is by sharing what breaks (and how we fix it).

Now go build something. Break it. Fix it. Ship it.

Let me share what I’ve learned about finding (and sometimes avoiding) Web3 talent.

The Reality of Web3 Development

First, let’s break down what actually happens in most Web3 projects:

1. dApp Architecture Design (a table or a paper)
2. Smart Contract Development (mostly Solidity for EVM’s)
3. Data Flow Management (things like alchemy API’s, subgraphs, etc)
4. Interface Creation (Figma, ReactJS, NextJS)

Here’s the thing: while the first part and the second requires specialized expertise, the rest is often repetitive work that eats up weeks or months of development time.

Where to Find Web3 Talent

If you need smart contract development, here’s where to look (and not look):

Traditional Platforms

• Upwork: Filter for developers with proven Web3 experience
• LinkedIn: Look for builders with public repositories
• X/Twitter: Follow Web3 dev communities
• Discord: Join developer communities

Web3-Native Channels

• ETH Global: Connect with hackathon winners
• Web3 Job Boards: Post specific requirements
• DeFi Communities: Network with builders (telegram and discord)

Red Flags in Web3 Hiring

Watch out for developers who:

1. Can’t explain gas optimization strategies
2. Have no experience with security best practices
3. Don’t ask about your tokenomics model
4. Promise unrealistic timelines
5. Can’t show previous Web3 work

The Cost Breakdown

Traditional Web3 development typically costs:

• Smart Contracts: $15–30k
• Frontend Development: $20–40k
• Testing & Audits: $10–20k
• Deployment: $5–10k

The Agency Trap

A quick note about Web3 agencies — something most won’t tell you:

Many agencies are essentially “freelancer wrappers” with a fancy website. Here’s what typically happens:

1. You pay the agency $100–300/hour
2. They subcontract to freelancers for $40–150/hour
3. You get the same talent, just at 2–3x the price

Why do people still use them?

• “Enterprise” feel
• Perceived reliability
• Formal contracts
• Project management

But here’s the reality I’ve seen building three blockchain startups:

Most agencies don’t have full-time developers. They:

• Hire freelancers per project
• Mark up rates significantly
• Add layers of management
• Slow down development with process

The result? A $50k project becomes $150k.

When Agencies Make Sense:

• You need full-stack Web3 development
• You have enterprise requirements
• You need formal contracts
• You have a large budget

When They Don’t:

• You have clear project scope
• You can manage developers directly
• You’re working with limited funds
• You need fast iterations

Ultimately, here’s what I’ve learned building dApps for clients who hit $30M+ market caps: much of this cost goes to repetitive frontend work.

The Alternative Approach

If you already have your smart contracts (or are working with a contract developer), here’s something most won’t tell you: you might not need to hire a frontend developer at all.

Why?

Because the frontend development process is largely repetitive. In fact, when building Web3Wizz, I noticed that developers often spend weeks on tasks that could be automated:

• Setting up data flow management
• Designing dApp architecture
• Creating interactive widgets
• Building user interfaces

The DIY Solution

Instead of hiring a frontend developer, consider these scenarios:

When to DIY:

• You have working smart contracts
• You need standard DeFi/NFT interfaces
• You want to launch quickly
• You’re working with limited resources
• You want to be in control of iterating

With tools like Web3Wizz, you can:

1. Paste your smart contract address
2. Select the functions you need
3. Add your brand colors & other settings
4. Launch securely in minutes, not months

When to Hire:

• You need custom smart contracts
• Your project requires unique features
• You have complex security requirements
• You need extensive backend integration

Real Results

We’ve seen this work with real projects. For instance, FX1 used Web3Wizz to transform their staking and unstaking process into a streamlined interface. What would have taken weeks of developer time was accomplished in hours.

Making the Choice

If you’re unsure which path to take, I offer free 30-minute strategy sessions where we can:

• Review your project requirements
• Assess technical feasibility
• Create an action plan
• Explore cost-effective solutions

Next Steps

1. If you have smart contracts ready: Try Web3Wizz Builder
2. If you need guidance or smart contracts: Schedule a strategy call

Remember: The goal isn’t just to build — it’s to build something users will actually use. Sometimes that means hiring the best developer you can find. Other times, it means using the right tools to do it yourself.

Ready to start building? [Launch Web3Wizz Builder] or [Book Your Free Strategy Call]

#Web3Development #DeFi #Blockchain #BuildWeb3

With that value in mind, we concluded that we need to run our application on top of decentralized ledger technology (DLT). Seeing how fast new DLT solutions are coming out, we made two assumptions:

1. New DLT solutions are being deployed every few months
2. Only a small subset of solutions out there have stood the test of time

With these two assumptions in mind, we realized that to address assumption number two in the list above we should aim for a solution that:

• is battle tested; has stood successfully the test of time
• supports smart contracts
• has a thriving and promising community of developers

With these constraints placed on our solution from our experience and research, it came to light that there is one solution that would fit us best now and that is Ethereum blockchain.

As important as our two requirements, it’s also vital to be backward compatible and future-proof, so we decided to build our application to be blockchain agnostic. The reasoning being is that there are enterprise players that have already invested in particular DLT solutions such as Corda, Hyperledger, Hashgraph and they may rightly want to leverage their current investments to achieve the outcomes that our application provides now or in the future. Therefore giving the capability of smart contracts, we can deploy Blocknify in any blockchain. Public, private, federated, permissioned, permissionless, with any underlying technology that supports smart contracts. We believe that goes in line with our strategy of giving more power and choice to our end consumer without confining them into a particular set of tech stack.

The main reasons that we decided to use a side-chain for our efforts instead of a public one are:

• Low Performance / High latency — Proof of Work ( PoW) takes a long time to approve transactions
• Transactional Privacy — Yes data is obscured however a private chain makes it fully private
• Trade Secrets — there are trade secrets that shouldn’t be available for the public to peek at

PoW can also be attacked by a high mining capacity which in a closed environment makes it more possible to overtake since the number of nodes is smaller, unlike on an open, public chain.

Our base blockchain offering for the B2C and our enterprise users who do not have an investment in blockchain solution yet is a federated Proof of Authority Ethereum client named ‘Clique’ that we have forked and slightly customized to fit our needs. We have deployed it, and it has a good number of running nodes that have been producing blocks and confirming Blocknify transactions the last 6+ months.

Our strategy which is in-process with the first nodes confirmed, then roll out the nodes within our enterprise customers environments who have full control over their nodes. In addition to having each one of their nodes, we tether our private chain to the public Ethereum network on an interval of every 300 blocks (with a setting of a block-a-second). This way using Patricia Merkel Tree root we can validate independently and store them in the main chain, an obscured hash of each block and guarantee that a block hash was a part of our blockchain at a given time. If any of the nodes are out of sync, not working, or malicious, we have developed a service that notifies all parties when such event occurs. Any of our enterprise customers are also welcomed to have their notification services based either on their node or within our arbitrator smart contract in the main net.

Having all these features in our approach to blockchain on top of which we build our solution we can guarantee the integrity of the data, the privacy and decentralization of resources that are used to ensure approval processes within the company and even between separate companies in our clientele.

Originally published at blog.blocknify.com.

At the beginning that looks like a big chunk of money depending on where you are located and what do you plan to do especially if your previous balance was zero. The reality of the situation, however, is that its very little and you have just started the overall journey of startup life. Having raised similar and more amounts with a few of my ventures I will share with you today a framework of thinking forged by many failures and successes on how to best move forward with your startup on your early stages and get maximum results while spending the least money as possible. These are no actual examples for your case, treat it more like a framework you can apply to any startup spending before Product-Market Fit.

Pre-Product-Market Fit

As Elon Musk famously said building a startup is like chewing glass and staring into the abyss, nothing could be truer especially before you have achieved product-market fit. Before you go out there with your product and ask people to pay for it you are basically in the dark with only two groups of opinions:

• skeptics — who will try to shut your venture down and
• supporters — usually friends and acquaintances who will elevate the idea and support you

However, in your quest of finding a real product-market fit, they are both equally unusable except for the much needed emotional support.

The question remains: How do we make the big leap into a validated product?

Start With Your Goals

It's important to have a few goals when you start a venture, you can get them by answering questions such as:

• Why am I doing this?
• If everything goes exactly how I want it to go, what would it all look like in the end?
• If I could have it all, what would it look like?

These questions can lead you to answer different questions, the answers to these questions you should hold on to for a while. When I founded Decissio the goal was to help investors make better investment decisions, now with all customers and additional raises, the goal still remains the same. Similarly, at Blocknify we aim to help people authorize and approve documents without sacrificing their privacy. These answers will be your background drum-marching music for quite some years so choose them wisely and let them guide you through your journey. My reasons for starting each of the companies is that I believe that venture funding should have higher rates of success and that I am frustrated when I have to print documents, sign them and mail them using physical mail to my bank every time I make an accounting change. Both of these are answers to my why’s. If “I could have it all” I would have it that every single investment decision is run against Decissio and every document is signed and approved using Blocknify. Fall in love with “If I could have it my way” exercises as a founder, really. They can help you solidify your vision outside of the daily grind.

As I am sharing my answers to these questions use them to find your own venture goals, or your northern star so to speak. Think of your whys and which ones resonate true to your core as an entrepreneur.

Cool, you got your goals narrowed down now what’s next?

Doubts

During our entrepreneurial journey, we talk with customers, investors, co-founders, mentors, and acquaintances. We write blogs like this one and we test to see which of our messages stick in the world. The process of getting it out there gives us some feedback on what’s working and what is not, and through these iterative process, some founder doubts are born.

If you are a founder and you have a doubt about your business, give this article a clap! All founders I’ve met have had their doubts about their company, product, and their process. Some of these are human mind-rumination that are not that important, the rest is pretty important.

As we are deploying our new application I sat down with my co-founder and we discussed what are some of the doubts that we have in relation to our private signature product and business. Before getting into it make sure that these are legitimate doubts that to some extent are confirmed from your investors, customers, and business partners too. As we are post-MVP now, we laid down that we needed to know if:

• Our B2C product is usable (do customers love it, or feel like ‘meh)?
• How to measure the success of public beta (what are the actual numbers)?
• Are we an attractive investment to crypto funds (all your ethers belong to us)?
• What about angel investors (Can we convince 10 people to give us 10k each)?
• What about our CEE region (Low startup funding, can we make it)?

These are some of the known unknowns that we had and now this is where the money comes in. In order to run a startup, you need to burn cash, every single month. Usually, as an entrepreneur, you have very limited resources and especially cash, so the main job of an entrepreneur is to make the maximum use of every unit your bank account shows. Large companies such as Microsoft and Apple can make a few mistakes, waste some money and still survive it all. In early stage startups, you are constantly 2 to 3 bad decisions away from a complete, devastating death of all your dreams and aspirations. That’s why the question of how should you spend your money is very important.

Whereas there are loads of unknown — unknowns that await you on your discovery journey, my point is that you should focus your time, money and energy on cracking down on your doubts and picking up the activities that will provide the most value to the company on answering these questions. After all, every early-stage startup is to an extent a product-market-fit experiment and if you are the founder, you are the scientist in charge of the lab. The cure you are looking to find with your experiment is a $1B+ evaluation. Anything below that, to place it in spiritual terms, means you are a seeker and not yet a finder.

After you have identified your legitimate doubts, its a good idea to brainstorm activities and tie resource values to them.

For example, if you do not know if your product is fully useable you can pick and choose from the following activities:

1. Perform user tests (paid and free, record the user interaction with your app)
2. Implement application user-behavior analytics (let the data do the talking)
3. Perform A/B testing
4. Find a company to do a pilot with

These sub-experiments should be done in such a way that in the end it provides a boolean answer to your doubt, answer in this case is: Yes our app is usable or not really.

Now, these are good ideas but a resource allocation should be placed next to it. Meaning — how expensive is each one of them to get an answer from?

If I get 5 friends to test my app and record it while they do it, I might have to buy them each a coffee or lunch, including my own time that might take me 3 hours to coordinate them, 5–7 hours to run the tests and a total of $100 in lunches. We have a number of hours and money involved to do that. If we do these tests we will get a clearer view of how people use our application.

The second one requires us to implement backend and front-end functionality, therefore, costing us a potential 80% of a sprint or a whole sprint — which is much more expensive.

Continue until you get all the options and all price tags next to them. Then run it down against the main goal and decide which one of them will bring the most of the results with the least of resources spent.

If you manage to run each decision through this lens, have reliable low burn rate $50k can take you a long way on your product-market fit search.

I have grown to look at product cycles as a Super Mario game, you need enough lives to move to the next level, and then you get a boost. The same goes for startups, you start with a little and if you can manage to validate and get traction well you get the “magic mushroom (read: funding)” to boost you to the next level. There are times though when you can get stuck on a particularly hard level for a long time, in this case, see and reevaluate what is working and what not.

On this challenging journey, I wish you the best! If any of the above points resonated with you, give it a clap and follow me for more maker stories!

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by + 375,041 people.

Subscribe to receive our top stories here.

How to Spend Your First $50k as a Startup was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

We will begin porting some of our functionality with IBM so we can create a more efficient turn over in our AI results in a more efficient manner. We will continue to experiment with new results while keeping the working sets as they are.

The other additional advance with IBM is that we can sell through them as a sales channel in the marketplace.

The initial results are positive and soon we will unveil Decissio 2.0.

Blocknify is humbled and honored to announce that we have been selected to Y Combinator’s Startup School — Advisor track.

We will be assigned an Advisor from YC’s fantastic alumni network. Not only will we learn from the YC’s team and mature as a company, but also help expand our network within Silicon Valley and worldwide.

This honor didn’t come without some proper drama.

If you haven’t heard, Y Combinator had a slip up resulting in about 12,000 startups receiving acceptance emails to only get an email a couple of hours later saying they slipped up the emails and they were not accepted. However, Y Combinator felt that they should own the slip-up and allow all the companies to participate for free without YC mentors.

We had a different experience, as we were one of the teams selected initially we received an email stating we were rejected. I guess they reversed the emails and sent acceptance letters to those rejected and rejection letters to those accepted.

Luckily the first email we saw was our acceptance email and not the rejection letter that was sent a couple of hours before. We got excited to be apart of the selected startups to receive an advisor, but that excitement quickly lead to confusion as we saw all the media attention about people being accepted when in reality they were rejected.

This created some confusion within our team slack with questions like ‘So did we make it?’ and ‘Should we celebrate or not?!’ After spending some time going back over the emails and re-reading the time-stamps, we were confident that we were accepted into the advisor track.

Unfortunately, this was not the ending for the other 12,000 teams who had their excitement shut down. These companies took to social media to announce this great achievement but to have Y Combinator follow up with an Oops email and then, accept them although without advisory. Everybody gets in! An experiment by Y Combinator results of which everyone is eager to see.

One tweet summed it up well ‘Welcome to #startuplife!’ All startups can relate too, as this path is full of these emotionally filled roller coaster moments.

In the end, our confidence has to come from our belief in the value we are creating, but this is whole a lot easier to say than remember. I believe that no moment is better than any other moment, but some are definitely more pleasurable than others 🙂.

Originally published at blog.blocknify.com on August 22, 2018.

Theoretically.

What gets overlooked however is that we as the dominant species on earth, that is something we gave the verdict on, have created super structures in our societies such as churches, kingdoms, central banks, governments, schools, health department, libraries, law enforcement, universities and banks.

These structures have helped our societies from presumedly diving into complete chaos. The tricky part is that as strong as their inclination is to keep our world from going into chaos, the same amount of pressure these structures wind up exercising against risky innovations which often do choke them.

Not by some evil conspiracy, but simply because we have created and placed these structures there to keep things the way they are. Because as people, we love more of what is, in some cases even of what was . As a proof of this one can see why more than we’d like we see political candidates that promise to bring back the “good ‘ol times" winning elections.

The number one occupation of structures that we have shaped our society around is to constantly produce more of the same. To illustrate, think of a time when a regulator got a big bonus because they allowed something through. Usually that does not happen, usually regulators are only punished when something they decide for, turns out to be wrong. So for a regulator, their incentive for voting yes on something benefital is simply not there.

Innovations, transformations and breakthroughs require the same amount of risk and chaos as the disruptive promise they hold within. Most of the time the society as a whole is unwilling to pay the price tag associated with potential benefits, that some crucified-by-media, weird looking, nerd sounding entrepreneur promises.

Because of these combined causes, progress on anything is not granted. We should never take progress for granted.

Next: How can we really support innovation