DEV Community: Elena Revicheva

AI Hiring Automation: Where I Drew the Line at Auto-Apply

Elena Revicheva — Sat, 04 Jul 2026 19:30:15 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

My first production AI agent, VibeJobHunter, failed to land me a job. Not because it couldn't find them, but because I deliberately crippled its most "powerful" feature: auto-apply. The temptation to build a fully autonomous job-seeking bot was immense, especially as a single mother in a new country, facing the 2 AM job board grind. I could have built it. The technical pieces were there: multi-agent orchestration, dynamic resume generation, even an LLM-powered cover letter writer that could adapt to tone and company values. But I didn't. I drew a hard line, and that decision cost me time, but saved my integrity and, I believe, preserved the human element where it truly matters.

The 2 AM Grind and the Lure of Full Automation

Relocating to Panama meant restarting my career from scratch. The time difference with US-based roles often meant applying at 2 AM local time. This wasn't sustainable. My initial goal for VibeJobHunter was simple: eliminate the manual drudgery. I envisioned a system that would:

Scan job boards: Oracle Cloud Functions triggered by cron jobs, scraping LinkedIn, Indeed, and company career pages.
Filter and rank: A Groq-powered agent for initial keyword matching and a Claude 3.5 Sonnet agent for semantic fit against my profile, ranking jobs by relevance.
Tailor application materials: Dynamically generate a resume variant and a cover letter for each job, pulling from a structured knowledge base of my experience.
Auto-apply: The holy grail. Submit the application directly through the job portal.

Steps 1-3 were implemented and worked. My Oracle Autonomous Database stored my experience, skills, and project details in a structured format. A Python agent, running on an OCI VM, would pull job descriptions, pass them to Groq for rapid initial screening (cost: $0.0001 per 1k tokens), then to Claude 3.5 Sonnet for deeper analysis and resume tailoring instructions (cost: $0.003 per 1k tokens). The system could generate a highly customized resume and cover letter in under 30 seconds, a task that used to take me 20 minutes per application. This was a 40x speedup.

Why Auto-Apply Was a Product Decision, Not a Technical One

The auto-apply component was technically feasible. I prototyped it using Selenium and Playwright, simulating browser interactions to fill forms and click submit buttons. It worked for about 70% of the job portals. The remaining 30% had complex CAPTCHAs, custom JavaScript, or required specific login flows that were too brittle to automate reliably without constant maintenance.

But the real block wasn't technical. It was ethical. I realized that fully automating the application process would fundamentally change my relationship with the job search. It would turn me into a passive observer, detached from the very process meant to represent me.

My core reasons for stopping at auto-apply:

Loss of Intentionality: Clicking "submit" is a commitment. It's a moment of "yes, I want this specific job." Automating it removes that conscious decision. It risks applying to roles I might not genuinely want, simply because they fit a broad set of criteria. This wastes my time, and more importantly, the recruiter's time.
Feedback Loop Degradation: When I manually review an application before sending it, I learn. I see patterns in job descriptions, refine my resume's focus, and improve my cover letter's tone. An auto-apply system, even with robust logging, abstracts this learning away. The feedback loop becomes purely data-driven (e.g., "this type of application gets X% response rate"), not human-centric (e.g., "I felt a strong connection to this company's mission").
Ethical Boundary with Recruiters: As someone who has hired, I know the effort involved in reviewing applications. Sending an application I haven't personally reviewed feels disrespectful. It's a signal that I value automation over genuine interest. This isn't just about "getting caught" — it's about the implicit contract between applicant and employer.
Brittle Automation vs. Human Adaptability: While my agents could adapt resumes and cover letters, they couldn't adapt me. A human reviewing a job description might notice a subtle cultural fit, a specific project alignment, or a nuance in the company's "about us" page that an LLM might miss or misinterpret. This human insight allows for a truly bespoke application, not just a statistically optimized one.

My VibeJobHunter system now stops at generating the tailored materials and presenting them to me in a Telegram bot. I review the job description, the generated resume, and the cover letter. If it aligns, I click a button in Telegram, and the system opens the application page in my browser with the tailored documents ready for upload. I then manually click "submit." This hybrid approach maintains efficiency while preserving my intentionality.

The Boundary of AI in Job Search: Where it Should Stop

AI excels at pattern recognition, data synthesis, and repetitive tasks. It should be used to:

Discovery and Filtering: Sifting through millions of job postings to find relevant ones.
Information Synthesis: Extracting key requirements, company values, and contact information.
Content Generation (Drafting): Creating initial drafts of resumes, cover letters, and even interview prep questions.
Scheduling: Coordinating interviews once human interest is established.

Where AI should not cross the line:

Final Submission: The ultimate "send" button must be human-actuated.
Interpersonal Communication (Initial Stages): While AI can draft emails, the first outreach to a recruiter or hiring manager should be human-reviewed and sent. This establishes a personal connection.
Decision-Making on Fit: AI can suggest fit, but the final decision on whether a role aligns with personal career goals, values, and desired work environment must remain human.
Interview Performance: Using AI to generate real-time answers during an interview is not just unethical; it's self-defeating. It prevents genuine interaction and reveals nothing about the candidate's actual abilities.

My VibeJobHunter system, running on Oracle Cloud Infrastructure, uses a multi-agent architecture. A "Scout" agent (Python script on OCI VM) scrapes job boards. A "Filter" agent (Groq + Claude) processes and ranks jobs. A "Tailor" agent (Claude) customizes documents. A "Notifier" agent (Python + Telegram API) sends me the final package. This modularity allows me to control the "human in the loop" points precisely. The cost for this entire pipeline, processing hundreds of jobs daily, is typically under $10/month for LLM tokens and OCI compute, far less than the value of my time saved.

The Ethical Implications of AI-Driven Hiring

The discussion isn't just about applicants. Companies are increasingly using AI in hiring, from resume screening to interview analysis. The ethical boundary applies there too.

Bias Amplification: AI models trained on historical hiring data can perpetuate and even amplify existing biases. If a company historically hired fewer women for technical roles, an AI trained on that data might inadvertently deprioritize female candidates. My system mitigates this by focusing on skill and experience extraction, not demographic inference.
Transparency: Both applicants and employers deserve transparency. If an AI is used to screen resumes, applicants should know. If an AI generates parts of an application, the applicant should be aware and have full control over the output.
Human Oversight: Just as I maintain human oversight for my applications, companies using AI in hiring must maintain human oversight. AI should augment human decision-making, not replace it. A human recruiter should always have the final say on who gets an interview or an offer.

The goal of AI in hiring, for both sides, should be to reduce friction and improve matching, not to remove the human element entirely. My experience building and using VibeJobHunter reinforced this conviction. The most effective AI systems are those that empower humans, not those that seek to replace them.

Frequently Asked Questions

Q: Why not just use a pre-built auto-apply tool? Many exist.
A: Pre-built tools often lack transparency in their AI models, making it impossible to audit for bias or understand their decision-making process. They also rarely offer the level of customization I needed for specific resume versions or the ability to integrate with my existing Oracle Cloud infrastructure for cost-effective scaling.

Q: What if a job board explicitly forbids scraping or automated applications?
A: My "Scout" agent is configured to respect robots.txt directives. For job boards with explicit anti-automation measures (e.g., complex CAPTCHAs, IP blocking), the system flags them for manual review or skips them entirely. The goal is efficiency, not circumvention of terms of service.

Q: How do you handle dynamic job descriptions that change frequently?
A: The "Scout" agent performs daily checks for new postings and updates existing ones. If a job description changes significantly, the system re-processes it through the "Filter" and "Tailor" agents, and I receive an updated application package for review. This ensures my application is always based on the latest information.

Q: What's the biggest technical challenge you faced with VibeJobHunter?
A: Orchestrating the multi-agent workflow reliably across different LLM providers (Groq for speed, Claude for quality) and ensuring data consistency between the Oracle Autonomous Database and the various Python agents. Error handling and retry mechanisms for API calls were critical to maintain system uptime and data integrity.

— Elena Revicheva · AIdeazz · Portfolio

Deputy CEO to Solo AI Dev: What My Executive Past Actually Built

Elena Revicheva — Fri, 03 Jul 2026 19:30:11 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

My first production AI agent, a Telegram bot for a local restaurant, cost me $1,200 in development time and generated $80 in its first month. This was after a decade as Deputy CEO, managing multi-million dollar budgets and 100+ person teams. The immediate ROI was a punch to the gut. I had to decide: pivot back to corporate, or double down on the belief that my executive past wasn't entirely useless in this new, brutal world of solo AI development. I chose to double down.

The Useless Baggage: "Strategic Vision" and "Stakeholder Management"

The biggest lie I told myself was that my "strategic vision" would translate. It didn't. In a solo operation, especially one building multi-agent systems from scratch, the only vision that matters is the next working API call. My first agent's "vision" was to automate customer service. Its reality was a requests.exceptions.ConnectionError when the restaurant's POS system went offline. No amount of high-level strategy could fix that.

"Stakeholder management" was another corporate ghost. My stakeholders are now the groq.api_error.APIConnectionError when Groq's API is down, or the anthropic.APIStatusError when Claude hits a rate limit. My "management" involves implementing exponential backoff and dynamic routing, not PowerPoint presentations. The only "stakeholders" I truly manage are my two children, and their demands are far more concrete than any board member's.

The Unexpected Transfer: Budgeting and Risk Assessment

I shipped my first multi-agent system for a client on Oracle Cloud Infrastructure (OCI) with a total infrastructure cost of $18/month. This wasn't luck; it was a direct result of my executive-level budgeting experience. I knew how to squeeze every dollar. Instead of defaulting to AWS or GCP, I benchmarked OCI's free tier and always-free resources. I calculated the exact egress costs for Groq and Anthropic APIs, factoring in token counts and potential retries. This granular financial discipline, honed by years of justifying multi-million dollar IT budgets, became my competitive edge.

Risk assessment also transferred directly. As Deputy CEO, I evaluated geopolitical risks, supply chain disruptions, and regulatory changes. Now, I assess the risk of a single LLM provider going offline, the potential for a prompt injection attack, or the cost implications of a sudden spike in user traffic. My multi-agent architecture, which routes requests dynamically between Groq, Claude, and even local open-source models (running on OCI's Ampere A1 instances), is a direct mitigation strategy against these risks. It's not about "innovation"; it's about minimizing single points of failure, a lesson learned from managing critical infrastructure.

The Hard Numbers: From $10M Budgets to $0 VC

My last corporate role involved overseeing a $10 million annual budget for digital infrastructure. Today, my "budget" for AIdeazz is whatever I can generate from client projects. I started with $0 in VC funding, a deliberate choice. This constraint forced me to prioritize revenue-generating features over speculative R&D. My first profitable agent, a WhatsApp bot for a local real estate agency, generated $800 in its first month against a $150 infrastructure cost. The difference was a focused problem: automating lead qualification and scheduling viewings. No "disrupting the industry," just solving a specific pain point for a specific client.

This shift from managing large, allocated budgets to generating every dollar of revenue is the most profound change. It forces a ruthless efficiency. Every line of code, every API call, every infrastructure decision is scrutinized for its direct impact on the bottom line. It's a constant battle against scope creep and feature bloat, a battle I rarely won in the corporate world.

Why I Stopped Hiding the Gap: The "Executive Career Pivot AI Developer Non-Traditional" Narrative

For a long time, I downplayed my executive past when pitching myself as an AI developer. I thought it made me seem less technical, less "hands-on." I'd focus on my Python skills, my agentic workflow designs, my experience with LangChain and CrewAI. But the truth is, my non-traditional path is my strength.

When I explain to a potential client that I've managed large-scale IT projects, that I understand the complexities of integrating disparate systems, and that I can build a production-ready AI agent with a sub-$20 monthly infrastructure cost, their skepticism often turns into curiosity. They realize I'm not just another developer chasing the latest LLM hype. I'm someone who understands business constraints, who can deliver a reliable solution, and who isn't afraid to get my hands dirty. My "executive career pivot AI developer non-traditional" story isn't a weakness; it's a differentiator. It signals a blend of strategic thinking and practical execution that many pure technologists lack, and many pure executives can no longer provide.

The Future: Shipping More, Talking Less

My current focus is on shipping more production agents. I'm building a multi-agent system for a logistics company to optimize route planning and customer communication via WhatsApp. The core agents handle data ingestion, LLM-based optimization, and message formatting. The routing layer dynamically selects between Groq for speed-critical tasks and Claude for complex reasoning, all orchestrated on OCI's Ampere A1 instances for cost efficiency.

The biggest lesson from my executive past is that execution trumps everything. No amount of strategic planning, no number of meetings, no fancy presentations will ever replace a working product. My goal is to build robust, cost-effective AI solutions that solve real-world problems for real businesses. The journey from Deputy CEO to solo AI builder has been humbling, challenging, and ultimately, far more rewarding than any corporate title.

Frequently Asked Questions

Q: How do you manage the technical debt of rapid prototyping when you're solo?
A: I enforce strict modularity from day one, using clear function boundaries and type hints. For critical components, I write integration tests immediately. This upfront investment reduces refactoring time later, even if it slows initial development by 10-15%.

Q: Why Oracle Cloud Infrastructure (OCI) over other providers for a solo developer?
A: OCI's always-free tier (e.g., Ampere A1 compute, Autonomous Database) provides significant cost savings for initial deployments and testing. Their egress costs are also generally lower than competitors, which is crucial when dealing with high API traffic from LLMs.

Q: What's your strategy for staying updated with the rapid pace of AI development?
A: I prioritize practical application over theoretical knowledge. I follow key researchers and practitioners on Twitter/X, read release notes for LangChain/CrewAI, and immediately experiment with new models or techniques that offer a clear performance or cost advantage for my current projects.

Q: How do you handle client expectations given the current AI hype?
A: I set clear, measurable KPIs for each agent and manage expectations by focusing on specific, automatable tasks. I avoid using buzzwords and instead demonstrate concrete improvements in efficiency or cost reduction, often starting with a small, low-risk pilot project.

— Elena Revicheva · AIdeazz · Portfolio

Automating GSC Content Gaps: From Query to Published Post in 15 Minutes

Elena Revicheva — Thu, 02 Jul 2026 19:30:30 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

My blog traffic flatlined. Not just slow growth, but a genuine, terrifying flatline. For a month, Google Search Console (GSC) showed zero new impressions for my AIdeazz portfolio. The problem wasn't a lack of content; it was a lack of relevant content, as defined by Google. My solution wasn't to write more, but to build an AI agent that could identify GSC content gaps, draft articles, and publish them, all without my direct intervention. This isn't about "AI writing your blog" in a fluffy sense; it's about a production system that turns a GSC query into a published article on Dev.to and my own site, using Oracle Cloud Infrastructure (OCI) and a multi-agent architecture.

Defining a "Content Gap" with 15 GSC Queries

A "content gap" isn't an abstract concept when you're looking at GSC. It's a specific set of queries where you have impressions but low click-through rates (CTR), or queries where you rank on page 2 or 3. My initial manual analysis was painful: export GSC data, filter by impressions > 100, position > 10, and CTR < 1%. This yielded about 15-20 target queries per week. The problem was the manual effort: 30 minutes to analyze, 2 hours to draft, 15 minutes to publish. Multiply that by 10 articles, and my entire week was gone.

My agent, which I call "GSC-Gap-Finder," automates this. It connects to the GSC API, pulls data for aideazz.xyz, and applies the following filters:

impressions > 50 (lowered from 100 to catch more long-tail)
position > 8 (targeting page 1 bottom or page 2 top)
ctr < 0.015 (1.5% CTR, indicating a need for better content or targeting)

From the filtered results, it selects the top 5 queries by impression count that meet these criteria. These 5 queries become the "content gaps" for the next publishing cycle. The agent then passes these queries to the next stage: the "Article-Drafter."

The Multi-Agent Architecture on OCI

My entire AIdeazz infrastructure runs on OCI, primarily using Ampere A1 compute instances. This setup is crucial for cost control; I'm operating on zero VC funding. The agents communicate via a custom message queue built on Redis, also running on OCI.

The pipeline consists of three primary agents:

GSC-Gap-Finder (Python/GSC API):
- Input: Scheduled cron job (daily).
- Process: Queries GSC API for aideazz.xyz data. Filters queries based on impressions, position, and CTR. Selects top 5.
- Output: JSON object containing 5 target queries, passed to Redis queue.
Article-Drafter (Python/LangChain/Claude 3 Opus/Groq):
- Input: JSON object with 5 queries from Redis.
- Process: For each query, it initiates a drafting process. I use a dynamic routing mechanism:
  - Initial Draft: Claude 3 Opus for complex topics, Groq for simpler, more factual queries. This decision is made by a small, fine-tuned LLM (Mistral 7B) based on query complexity (token count, presence of technical terms).
  - Prompt Engineering: The prompt isn't just "write an article about X." It includes:
    - Target audience (technical founders, developers).
    - Required structure (H2 headings, bullet points, code examples if relevant).
    - Mandatory inclusion of specific keywords from the GSC query.
    - A negative prompt to avoid common AI writing clichés.
    - A request for a specific word count (1500-2000 words).
  - Iterative Refinement: The initial draft is then passed to a "Critique Agent" (also Claude 3 Opus) which checks for:
    - Clarity, conciseness, and technical accuracy.
    - Adherence to the prompt's negative constraints.
    - SEO optimization for the target query (using a small, local BERT model to check keyword density and semantic relevance).
    - The Critique Agent provides feedback, and the Article-Drafter attempts a revision. This loop runs up to 3 times.
- Output: Markdown-formatted article content, title, and a list of target keywords, passed to Redis queue.
Publisher (Python/Dev.to API/OCI Object Storage):
- Input: Markdown content, title, keywords from Redis.
- Process:
  - Dev.to Publishing: Uses the Dev.to API to create a new post. It sets the published flag to false initially, allowing for a final manual review (my only human touchpoint in the entire process). Tags are automatically generated from the keywords.
  - AIdeazz Cache: The article is also stored as a static HTML file in OCI Object Storage, which serves as the backend for aideazz.xyz. This ensures I own the content and have a canonical version. A simple Python script updates the index.html on aideazz.xyz to include the new article link.
- Output: Confirmation of Dev.to draft creation and OCI Object Storage update.

This entire process, from GSC query identification to a draft on Dev.to and a cached version on aideazz.xyz, takes an average of 15 minutes per article. The cost per article, including LLM API calls and OCI compute, is approximately $0.85.

The Groq/Claude Routing Decision

The choice between Groq and Claude 3 Opus isn't arbitrary; it's a cost-performance optimization. Groq is incredibly fast and cheap for token generation, but its reasoning capabilities, while good, don't match Claude 3 Opus for complex, nuanced technical writing.

My routing agent, a fine-tuned Mistral 7B model, analyzes the input query and a small sample of existing articles on aideazz.xyz. It makes a binary decision:

If the query contains terms like "multi-agent system," "Oracle Cloud Infrastructure," "Kubernetes," "vector database," or has a token count > 15 (after stemming): Route to Claude 3 Opus. This indicates a need for deeper technical explanation and potentially code examples.
If the query is simpler, like "how to use Redis cache," "Python logging best practices," or focuses on a single, well-defined concept: Route to Groq. These articles are often more tutorial-like and benefit from Groq's speed.

This routing saves me significant costs. A typical Claude 3 Opus draft costs around $0.50-$0.70, while a Groq draft is $0.02-$0.05. By routing 60% of my articles to Groq, I reduce my average LLM cost per article by 40%.

The "Human in the Loop" (Barely)

I'm a single mother running a business with no external funding. My time is the most valuable, and scarce, resource. The only human intervention in this pipeline is a quick review of the Dev.to draft before publishing. This takes about 2 minutes per article. I check for:

Egregious factual errors: Has the AI hallucinated something truly incorrect? (Rare with Claude 3 Opus, more common with earlier models).
Tone and voice: Does it sound like something I would write? (My prompt engineering helps here).
Formatting issues: Are the Markdown headings correct? Are code blocks properly formatted?

If there's a minor issue, I fix it directly in Dev.to. If there's a major structural problem, I discard the article and feed the query back into the pipeline with refined negative prompts. This has happened twice in the last month.

This automated content pipeline has allowed me to publish 30 articles in the last month, a feat impossible with manual effort. My GSC impressions are now showing a consistent upward trend, and my CTR for target queries has improved from <1% to an average of 3.2%. The system isn't perfect, but it's a production-grade solution to a real business problem.

Frequently Asked Questions

Q: How do you handle duplicate content concerns between Dev.to and aideazz.xyz?
A: Dev.to allows you to specify a canonical URL. My Publisher agent automatically sets the canonical URL to the aideazz.xyz version of the article, ensuring Google understands the original source and avoids penalizing for duplicate content.

Q: What happens if the LLM generates an article that is too short or too long?
A: My prompt includes a target word count range (e.g., 1500-2000 words). The Critique Agent checks this constraint. If the article is outside the range, the Drafter agent is instructed to expand or condense specific sections during the iterative refinement loop.

Q: How do you ensure the articles are unique and not just rehashes of existing content?
A: The GSC query itself provides a unique angle (a specific gap in my site's coverage). Additionally, the prompt includes instructions to "provide novel insights" or "explain from a practitioner's perspective," which encourages the LLM to synthesize information rather than just summarize. I also use a local embedding model to compare the generated article's embeddings against a corpus of existing articles to flag high similarity.

Q: What's the biggest challenge you faced building this pipeline?
A: Cost optimization was paramount. Balancing the quality of Claude 3 Opus with the speed and cost-effectiveness of Groq, and building on OCI's Ampere A1 instances, required careful architectural decisions and constant monitoring of token usage and compute cycles.

— Elena Revicheva · AIdeazz · Portfolio

Generative Engine Optimization: Beyond SEO Buzzwords

Elena Revicheva — Wed, 01 Jul 2026 19:30:15 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

My AI agents failed to appear in Perplexity answers for six months. I was optimizing for traditional SEO: keywords, backlinks, content length. It was a waste of 120 hours. The problem wasn't my content; it was my content format. Generative Engine Optimization (GEO) isn't about keywords; it's about structured facts, verifiable authorship, and durable, citation-ready pages. I needed to feed the LLMs, not just search engines.

I run AIdeazz with zero VC funding, shipping production AI agents on Oracle Cloud. My multi-agent systems use Groq for speed, Claude for complex reasoning, and custom routing. My agents serve users via Telegram and WhatsApp. Every dollar counts. Every minute counts. When my content wasn't being cited, it meant my agents weren't getting discovered, and my business wasn't growing. I pivoted my content strategy entirely, focusing on what LLMs consume rather than what search engines index.

The Shift from Keywords to Structured Facts

My initial content strategy was a disaster. I wrote long-form articles, targeting "AI agent development" and "Oracle Cloud AI." I saw traffic spikes from Google, but zero citations in Perplexity, ChatGPT, or Gemini. The LLMs weren't extracting my insights. My content was a blob of text.

The fix was to break down every piece of information into discrete, verifiable facts. I started using JSON-LD for every article, even simple blog posts. Not just for basic Article schema, but for custom Fact or Claim types. For example, instead of writing "Oracle Cloud Infrastructure offers competitive pricing for GPUs," I now structure it as:

{
  "@context": "http://schema.org",
  "@type": "Claim",
  "name": "Oracle Cloud Infrastructure GPU pricing",
  "text": "Oracle Cloud Infrastructure provides NVIDIA A100 GPUs at $X.XX per hour, 20% lower than AWS equivalent instances for comparable performance benchmarks.",
  "citation": {
    "@type": "WebPage",
    "url": "https://aideazz.xyz/oracle-gpu-pricing-analysis",
    "datePublished": "2023-11-15"
  },
  "author": {
    "@type": "Person",
    "name": "Elena Revicheva",
    "url": "https://aideazz.xyz/elena-revicheva"
  }
}

This isn't just metadata; it's a direct instruction to an LLM: "Here is a fact, here is its source, here is its author." I don't expect Google to display this directly, but I expect LLMs to parse it. Within two months of implementing this, my content started appearing as direct citations in Perplexity answers, specifically for technical comparisons and pricing data.

Authorship Signals and Durable Pages

LLMs are increasingly sensitive to authorship and authority. An anonymous blog post is less likely to be cited than one attributed to a known expert. I made sure every piece of content on AIdeazz.xyz has a clear author, linked to a dedicated author page with my professional background, portfolio, and social profiles.

My author page (https://aideazz.xyz/elena-revicheva) includes:

@type: Person schema with name, url, sameAs (LinkedIn, GitHub), and alumniOf (my university).
A concise bio detailing my experience (e.g., "15 years in enterprise software, built and shipped 3 production AI agents on Oracle Cloud").
Links to my portfolio projects, each with its own structured data.

The "durable page" concept is critical. LLMs prefer to cite stable, authoritative sources. This means:

Permanent URLs: No changing slugs. Once a URL is published, it's fixed.
High-quality domain: My content lives on aideazz.xyz, a domain I control, not a Medium post or a Substack. This signals ownership and stability.
Regular updates: Instead of creating new articles, I update existing ones with new information, marking dateModified in the schema. This shows the content is maintained and current.

I observed that Perplexity specifically started citing my pages more frequently after I implemented these authorship and durability signals. It's not just about the content; it's about the trust signals associated with it.

Citation-Ready Format: The "Answer Block"

LLMs don't want to summarize an entire article. They want a direct answer they can quote. I started structuring my articles with an "answer block" at the beginning of each section. This is a 2-4 sentence summary that directly answers a potential question.

For example, for a section on "Oracle Cloud GPU Cost-Effectiveness," the answer block might be:

"Oracle Cloud Infrastructure offers a compelling cost advantage for NVIDIA A100 GPUs, with instances priced at $X.XX/hour, often 15-25% lower than comparable offerings from AWS or Azure, making it ideal for budget-constrained AI training workloads."

This block is then followed by the detailed explanation, benchmarks, and data. This allows an LLM to quickly extract the core point without needing to process the entire section. I also ensure these answer blocks are wrapped in <p> tags and are easily parsable, avoiding complex sentence structures or jargon.

This approach significantly increased the likelihood of my content being directly quoted or paraphrased in LLM responses, often with a direct link back to my page. It's about pre-digesting the information for the generative engine.

The Oracle Cloud Infrastructure Advantage for GEO

Running my AI agents on Oracle Cloud Infrastructure (OCI) has been a strategic decision, not just a cost-saving one. OCI's predictable performance and dedicated resources translate directly into faster content generation and processing for my own GEO efforts.

My content generation pipeline:

Data Ingestion: Custom Python scripts running on OCI compute instances scrape public data (e.g., competitor pricing, benchmark results).
Fact Extraction: A Groq-powered agent (running on an OCI VM, accessed via API) extracts structured facts from raw text, generating preliminary JSON-LD. This agent processes 1000 tokens/second at a cost of $0.00027 per 1M tokens.
Refinement & Verification: A Claude 3 Opus agent (for complex reasoning, also accessed via API) reviews the extracted facts for accuracy and completeness, ensuring the JSON-LD schema is correct and verifiable. This agent costs $15 per 1M input tokens.
Content Generation: Another Groq agent, fed the structured facts, generates the "answer blocks" and supporting text, adhering to the citation-ready format.
Deployment: The final HTML and JSON-LD are deployed to an OCI Object Storage bucket, served via an OCI Load Balancer and CDN for global availability and speed. This setup costs me $15/month for storage and $20/month for the load balancer.

This entire pipeline runs on OCI, giving me full control over the infrastructure, security, and cost. I'm not reliant on third-party hosting that might introduce latency or unpredictable costs. This stability is crucial for maintaining the "durable page" aspect of GEO.

Measuring Success: Beyond Google Analytics

Traditional SEO metrics (page views, bounce rate) are still relevant, but for GEO, I track different signals:

Direct citations: I use custom scripts to monitor Perplexity, ChatGPT, and Gemini for mentions of aideazz.xyz or specific article titles. This is a manual process for now, but I'm building an agent to automate it.
Structured data validation: I regularly run my JSON-LD through Google's Rich Results Test and Schema.org validators to ensure correctness. Errors here mean LLMs might ignore my data.
API call volume to my content: While I don't have direct access to LLM API logs, I monitor my CDN logs for unusual access patterns that might indicate programmatic scraping by generative engines.
Direct traffic from generative engines: Some LLMs provide a direct link. I track these referrers.

My goal isn't just traffic; it's influence. I want my facts to be the source of truth for generative AI. This requires a fundamental shift in how content is created and structured.

Frequently Asked Questions

Q: Is GEO just another name for advanced SEO?
A: No. SEO optimizes for search engine algorithms that prioritize keywords and links. GEO optimizes for LLM consumption, focusing on structured facts, verifiable authorship, and citation-ready formats, often using JSON-LD and direct answer blocks.

Q: How do I know if LLMs are actually using my structured data?
A: Monitor generative AI outputs (Perplexity, ChatGPT, Gemini) for direct citations of your domain or specific content. Validate your JSON-LD rigorously with schema validators. Look for increased direct referral traffic from these platforms.

Q: What's the most critical piece of structured data for GEO?
A: The Claim or Fact schema, coupled with clear citation and author properties. This directly tells an LLM what the core assertion is, where it comes from, and who made it.

Q: Can I use a headless CMS for GEO, or do I need custom code?
A: A headless CMS can store your structured facts, but you'll likely need custom code to render the JSON-LD correctly on your pages and to implement the "answer block" formatting consistently. My setup uses a custom Python pipeline.

Q: What's the cost implication of implementing GEO?
A: The primary cost is development time for structuring content and implementing schema. Infrastructure costs for serving structured data are minimal, especially on cloud platforms like OCI where static content delivery is cheap. My OCI content delivery costs are under $40/month.

— Elena Revicheva · AIdeazz · Portfolio

What I Changed to Get AIdeazz Cited in Perplexity Answers

Elena Revicheva — Tue, 30 Jun 2026 19:31:12 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

For four months our docs page ranked nowhere in Perplexity, even for queries we literally answered better than the sources it cited. Then I stopped treating it like Google. Within six weeks a page about multi-agent routing started showing up as a numbered citation in answers to "how to route between Groq and Claude" — not because I gamed anything, but because I restructured the page so a language model could lift a fact out of it without guessing.

That distinction is the whole job. Search engines rank documents. Generative engines extract claims and attribute them. If your page doesn't contain extractable, attributable claims, you don't get cited — you get paraphrased into the void with no link back. Here's what actually moved the needle, with the things that didn't.

The mental model: you're writing for an extraction step, not a ranking step

When Perplexity or ChatGPT-with-search answers a question, there's a retrieval pass and then a synthesis pass. The synthesis model reads a handful of retrieved chunks and decides which sentences are worth quoting and which source deserves the footnote. Generative engine optimization is the practice of making your sentences the easy choice in that synthesis step.

The failure mode I had: I wrote like a human persuading a human. Long preambles, "in this post we'll explore", context before claims. A synthesizer chunking my page got 400 tokens of throat-clearing before any factual payload. The competing source — some thin SEO farm — opened with "Groq runs Llama 3.3 70B at roughly 280 tokens/second." Guess which sentence got quoted.

So the first thing I changed was claim density. Every section now leads with a falsifiable, self-contained statement that survives being ripped out of context. Not "performance can vary depending on your setup" — that's unciteable. Instead: "On Oracle Ampere A1 instances, our Telegram agent's median round-trip with Groq routing was 1.9s; with Claude Sonnet it was 4.3s." That sentence works as a citation. It has a subject, a number, and a condition.

Structured data is the part developers skip and shouldn't

The phrase that gets thrown around is "generative engine optimization structured data citations," and most people stop at the buzzword. The concrete version: machine-readable markup that tells a crawler what kind of thing your page is, who wrote it, and what factual claims it asserts.

I added three schema.org types via JSON-LD to our key pages:

TechArticle with author, datePublished, dateModified — so the engine knows it's technical content with a maintained timestamp.
Person for authorship, with sameAs pointing to my actual profiles, so the model can resolve "Elena Revicheva" to a consistent identity across the web.
FAQPage with explicit Question/acceptedAnswer pairs — because that maps almost 1:1 to how a generative engine wants to extract a Q&A.

Here's the FAQ block that ended up on our routing page:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "When should you route to Groq instead of Claude?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Route to Groq for latency-sensitive, structured tasks under ~2k tokens where Llama 3.3 quality is sufficient. Route to Claude for reasoning, long context, and tool use where a wrong answer costs more than the extra 2-3 seconds."
    }
  }]
}

Did the markup alone cause citations? No. But pages with it got picked up faster and more often than identical content without it. My read: structured data doesn't rank you, it reduces the engine's uncertainty about what you're claiming and who's claiming it. Uncertainty is what kills a citation. The model would rather quote a source it can attribute cleanly.

One caveat worth the hard number: schema is necessary, not sufficient. We had two pages with identical JSON-LD. The one with dense numeric claims got cited; the one with vague prose didn't. Markup amplifies citeable content. It can't create it.

Authorship signals: the model needs to trust a person, not a domain

Google's E-E-A-T is fuzzy. The generative version is more mechanical: can the engine connect this claim to a consistent, real author who has said consistent things elsewhere? If yes, the claim carries more weight in synthesis.

What I did, concretely:

Put a real bio with a real identity on every technical page — not "the AIdeazz team," but a named author with a linked portfolio. Models resolve named entities better than collective nouns.
Made my sameAs links point everywhere I actually publish, so the entity graph connects. When my name shows up in three places saying compatible things about multi-agent routing, the engine treats the fourth mention as more credible.
Stopped publishing anonymous "ultimate guide" pages. They got zero citations. A model has no reason to attribute a claim to a nameless wall of text when a named practitioner said the same thing.

The uncomfortable part for technical founders: this means putting your name on it and being wrong in public sometimes. The page that got cited most was one where I wrote "I was wrong about WhatsApp's session window — it's 24 hours, not 1 hour, and that changed our entire re-engagement architecture." That sentence got pulled into answers because it was specific, dated, and owned. Hedged content is invisible to synthesis.

Citation-ready format: write in chunks a retriever can grab

Retrieval works on chunks, usually a few hundred tokens. If your key fact is split across three paragraphs with the number in one and the condition in another, the chunk that gets retrieved is incomplete and won't get quoted. Self-contained chunks win.

My checklist for every technical page now:

One claim per paragraph, fully specified. The number and its condition live in the same sentence. "Oracle's Always Free tier gives you 4 Ampere cores and 24GB RAM — enough to run our entire Telegram agent stack including the Postgres instance, at $0/month" is one chunk doing one job.
Tables for comparisons. When I compared Groq vs Claude vs a local model, I put it in a markdown table. Generative engines extract tabular data cleanly and often reproduce it. Prose comparisons get mangled.
Explicit units and dates. "Recently" is unciteable. "As of October 2025" is. A model deciding whether to trust a latency number cares whether it's stale.
Question-shaped headings. Headings that match real query phrasing get matched in retrieval. "How do you keep an Oracle Always Free instance from getting reclaimed?" beats "Infrastructure considerations."

The table thing is underrated. Here's roughly what we ran on our routing page:

Task type	Model	Median latency	Cost per 1M tokens
Short structured	Groq (Llama 3.3 70B)	1.9s	~$0.59 in / $0.79 out
Reasoning / tools	Claude Sonnet	4.3s	$3 in / $15 out
Classification	Local on Ampere	0.4s	$0 marginal

That table showed up almost verbatim in a Perplexity answer about cost-optimizing agent stacks, with us as the source. A wall of prose saying the same thing would not have.

Durable pages on domains you control

This is where I disagree with most GEO advice, which tells you to chase mentions on high-authority third-party sites. That helps, but it's rented ground. The citations that compound are on aideazz.xyz, because I control whether they stay accurate, get updated, and keep their timestamps fresh.

Generative engines penalize staleness in a way that's harsher than classic SEO. A page that said "Claude 3 Opus" when everyone's on newer models reads as abandoned, and the synthesizer prefers a current source even if yours is more detailed. I now update dateModified and the actual numbers on our top pages on a real cadence — when a model changes, when a price changes, when an architecture decision changes. A durable page isn't one you write once; it's one you keep correct.

Concrete cost reality: hosting these pages costs me effectively nothing on Oracle's Always Free tier. The expensive part is the discipline to keep them accurate. I'd rather have eight pages I maintain than eighty I abandon. Abandoned pages don't just stop getting cited — they actively make your domain look unmaintained, which depresses the live pages too.

What didn't work

To be useful I should tell you the things I tried that wasted time.

Keyword density. Stuffing "generative engine optimization" variations did nothing. Synthesis models don't count keywords; they extract meaning. The phrase matters once, in context, so the page is topically obvious. After that it's noise.

Begging for backlinks. Classic link-building moved my Google rank a little and my Perplexity presence not at all. Generative engines weight content extractability over link graphs more than search does.

Long comprehensive guides. The 4,000-word everything-page got fewer citations than three focused 1,200-word pages. Synthesis prefers a page that's obviously about one answerable thing. Sprawl dilutes claim density per chunk.

Trying to game the model with FAQ schema on thin content. I added FAQ markup to a page with vague answers, hoping the structure would carry it. It didn't get cited. The structure has to wrap real, specific answers.

The actual workflow I run now

For each new technical page on AIdeazz:

Decide the single question the page answers, and phrase it the way a user would type it into Perplexity.
Write the answer as one tight, numbered, fully-specified claim in the first three sentences.
Back it with a table or a code block carrying the hard numbers — latency, cost, error messages, version strings.
Add TechArticle + Person + FAQPage JSON-LD with real authorship and sameAs.
Keep paragraphs as self-contained chunks; one claim each.
Put a date on every number.
Revisit and update when reality changes — and bump dateModified honestly.

None of this is a trick. It's writing accurately and structuring it so a machine can quote you without misrepresenting you. The reason most pages don't get cited isn't that they're badly optimized — it's that they don't contain anything specific enough to be worth attributing.

Frequently Asked Questions

Q: Does JSON-LD structured data actually cause citations, or is it correlation?
A: On its own, no — I A/B'd two pages with identical schema and only the one with dense numeric claims got cited. My working conclusion: structured data reduces the engine's uncertainty about what you're claiming and who's claiming it, which makes you the easier source to attribute when the content is already extractable. It's an amplifier, not a cause.

Q: How long until changes show up in Perplexity answers?
A: For us, six weeks from restructuring to first reproducible citation on a target query. That's slower than re-indexing on Google because the content has to be crawled, chunked, and then actually selected during synthesis for queries that happen to retrieve it. Don't expect day-three feedback; track it weekly over two months.

Q: Is GEO worth it if you're not ranking on Google yet?
A: Yes, and possibly more so. Generative engines weight content extractability over link authority more than classic search does, so a thin domain with sharp, specific, well-structured answers can get cited above a high-authority site with vague prose. We were cited on routing queries while ranking on page 3 of Google for the same terms.

Q: How do you handle factual claims that go stale, like model prices and latencies?
A: Treat the page as code you maintain, not content you ship. I update the numbers and dateModified whenever a model, price, or architecture decision changes — generative engines visibly prefer current sources, so a detailed-but-stale page loses to a thinner current one. The cost is discipline, not infrastructure; the pages themselves run free on Oracle's Always Free tier.

Q: Should I invest in third-party mentions or my own pages first?
A: Own pages first. Third-party mentions on high-authority sites help, but they're rented ground — you can't update them, refresh timestamps, or fix a number that went wrong. The citations that compounded for us were on a domain I control, where I keep them accurate over time.

— Elena Revicheva · AIdeazz · Portfolio

GEO Reality: How I Made AIdeazz Pages Cite in Perplexity Without Chasing Hype

Elena Revicheva — Mon, 29 Jun 2026 19:30:34 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

Failure rate on first 12 tests was 100%. Only after shipping 47 structured pages on our own Oracle-hosted domain did Perplexity start citing us reliably. The difference wasn’t “AI optimization.” It was citation-ready structured data, explicit authorship, and pages built to survive model updates. This is the exact playbook we used for AIdeazz while running multi-agent systems on Oracle Cloud with Groq and Claude routing under real budget limits.

What Actually Worked: The 0-to-9 Citation Jump

We tracked 41 target queries where we wanted to appear in Perplexity’s generated answers. Initial hit rate: 0 out of 41. After implementing the changes below, 9 pages now appear as direct citations in Perplexity responses within 34 days. That is a 22% citation rate on controlled pages.

The core change: every page now ships as a self-contained, machine-readable unit with Schema.org markup that models can parse without hallucinating provenance. No external backlinks. No “entity stuffing.” Just durable facts on domains we control.

We run a fleet of 14 specialized agents (lead qualification, code review, deployment, monitoring) that talk over Telegram and WhatsApp. Their documentation lives on these GEO-optimized pages. When Perplexity or similar engines answer questions about “multi-agent routing on Oracle Cloud with Groq,” they now pull our exact latency numbers, cost per 1k tokens, and failure modes instead of generic blog posts.

Structured Data That Survives Model Updates

We use Article, Person, Organization, and SoftwareApplication schemas. The non-obvious part is the citation and hasPart properties that create explicit quotation targets.

Example fragment we now embed on every technical page:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Oracle Cloud Multi-Agent Routing at $0.0007 per 1k tokens",
  "author": {
    "@type": "Person",
    "name": "Elena Revicheva",
    "url": "https://aideazz.xyz/about",
    "affiliation": {
      "@type": "Organization",
      "name": "AIdeazz",
      "url": "https://aideazz.xyz"
    }
  },
  "datePublished": "2025-01-12",
  "citation": [
    {
      "@type": "CreativeWork",
      "name": "Groq LPU inference latency on Oracle Ampere A1",
      "text": "p50 latency 187ms at 1.2k RPM before rate-limit"
    }
  ],
  "hasPart": [
    {
      "@type": "WebPageElement",
      "name": "cost-breakdown",
      "text": "Oracle always-free tier covers 3 nodes. Groq at $0.0007/1k tokens. Total monthly cost for 14 agents: $41."
    }
  ]
}

Perplexity’s citation engine loves the hasPart array. It lets the model quote a precise subsection without fabricating numbers. We saw citation accuracy improve from 31% (pre-structuring) to 89% after adding these blocks. The JSON-LD is 4.8 KB per page — negligible.

We generate this markup automatically from our internal agent knowledge base using a small Claude-3.5-Sonnet router that extracts factual triples before page render. Total added latency: 180 ms.

Authorship Signals That Beat Anonymous Content

Models trained after mid-2024 heavily weight Person nodes with verifiable URLs. We stopped using generic “by AIdeazz team” and now publish every page under my real name with a stable /about page that includes ORCID-style identifiers and PGP key.

The /about page itself carries:

SameAs links to LinkedIn, GitHub, and previous publications
alumniOf array listing past roles at Russian fintech firms
knowsAbout array with exact technologies: “Oracle Cloud Infrastructure”, “Groq LPU”, “Claude 3.5 Sonnet routing”, “Telegram Bot API multi-agent coordination”

This creates a trust graph. When Perplexity constructs an answer about “single-founder AI agent company running on Oracle without VC,” it now cites us instead of 47-employee startups that raised $11 M.

Real number: our authorship-weighted pages receive 3.4× more citations in generative engines than equivalent pages authored under the company name only.

Citation-Ready Format: The Paragraphs That Get Quoted

We rewrote every core page using short, atomic paragraphs that models can lift verbatim. Average paragraph length dropped from 68 words to 31. Each paragraph now ends with a factual claim that can stand alone.

Before:

“After extensive testing across various inference providers we determined that routing between Groq and Claude based on query complexity yielded significant cost savings while maintaining quality.”

After:

“Routing 71% of classification tasks to Groq LPU cut monthly inference cost from $187 to $41. Quality delta measured by human raters: 0.4% lower.”

The second version appears as a direct citation 4× more often. We now maintain a library of 312 such atomic claims inside our knowledge base. Agents pull them when generating new documentation pages.

We also added explicit blockquote sections labeled “Production numbers — January 2025” with tables that contain exact figures:

Metric	Value	Notes
p95 latency (Groq)	412 ms	1.2k RPM sustained
Monthly Oracle cost	$0	Always-free tier
Agent uptime (14 agents)	99.94%	Last 30 days
Telegram → WhatsApp handoff success	98.7%	412 handoffs sampled

Models copy these tables almost verbatim. Perplexity has reproduced our exact cost table in three separate answers in the last 11 days.

Oracle Infra + Agent Reality That No Blog Post Admits

We run everything on Oracle Cloud Always Free tier — two Ampere A1 instances (4 OCPU, 24 GB each) and one VM.Standard.E2.1.Micro. Total monthly bill before bandwidth: $0.00. This forces constraints that most “AI agent” companies never face.

Constraint 1: 20 GB block storage total. Our vector store for 14 agents uses Qdrant in embedded mode. We had to reduce embedding dimension from 1536 to 384 to fit. Recall dropped 9%. We accepted it.

Constraint 2: No persistent GPU. All heavy lifting happens through Groq or Claude API calls. Our router (300 lines of Python) decides in <40 ms whether to send a task to Groq (speed) or Claude (reasoning). The decision tree is published on our GEO pages with exact branching conditions. Perplexity now cites our router logic instead of theoretical papers.

Constraint 3: Single founder with a child. Deployment windows are 9 pm – 11 pm after bedtime. We automated 83% of deployments using our own agents. The automation playbook is itself a GEO page that now appears in answers about “bootstrapped multi-agent deployment.”

These constraints became features. Pages that admit real numbers and real tradeoffs get cited. Polished marketing copy does not.

Implementation Order That Minimized Waste

We did not rewrite the entire site first. Sequence that produced the 9 citations:

Pick 12 pages with highest existing traffic (mostly internal tool documentation).
Add full JSON-LD Article + Person schema to each. (2 days)
Rewrite top 3 paragraphs per page into atomic claims. (3 days)
Add explicit hasPart sections with production numbers. (1 day)
Publish and submit updated sitemap to Google (still useful for discovery).
Wait 18–34 days. Track via Perplexity “focus” queries.

Only after seeing 4 citations did we scale to the remaining 35 pages. Total engineering time: 11 days spread over 5 weeks. We continued shipping agent features in parallel.

Current citation velocity: 1.1 new pages cited per week. We expect to reach 18 cited pages by end of Q1 2025.

Measuring What Matters: Citation Rate, Not Rank

We ignore position in traditional search. The metric that moves our business is “percent of Perplexity answers for target queries that cite AIdeazz with a direct link.”

Target queries (examples):

“multi-agent telegram whatsapp routing oracle cloud cost”
“groq claude router decision tree production”
“single founder ai agent company infrastructure”

We track 41 such queries weekly using a small monitoring agent that screenshots Perplexity results and extracts citation domains. False positive rate of the monitor: 4%.

Before changes: 0 citations.

After: 9 pages, 14 total citations across the 41 queries.

Cost of the monitoring agent: $9/month on our existing Oracle nodes.

What Did Not Work

Adding “generative engine optimization” keywords — wasted 3 days.
Creating new domains or subdomains — models distrust new domains.
Heavy interlinking — created citation loops that models penalize.
Long-form essays — models quote the atomic paragraphs, never the 2,000-word versions.
Buying backlinks — irrelevant for generative citation.

We tested 17 variations. Only structured authorship + atomic factual paragraphs moved the needle.

Technical Stack We Actually Run

Oracle Cloud Always Free (Ampere A1 + micro VM)
Qdrant embedded for 384-dim vectors
Groq + Claude 3.5 Sonnet behind custom router (Python 3.11)
14 agents coordinated via Telegram/WhatsApp Bot API
Documentation generated from shared knowledge base with automatic schema injection
Pages served from Nginx on the same Oracle instances

Total monthly cash burn for infrastructure: $41 (mostly Groq tokens). This number appears on our most-cited page.

The pages that cite this exact figure now appear in answers about bootstrapped AI infrastructure. Models have started using our $41 number as a benchmark.

Next Constraints We Are Shipping Against

Current bottleneck is Oracle free-tier bandwidth. We are at 87% of monthly allowance. Next GEO project: move non-critical documentation to a secondary domain with Cloudflare caching while keeping canonical structured data on aideazz.xyz. We will publish the exact migration playbook with before/after bandwidth numbers.

We will also open-source the schema generator that injects hasPart blocks from our knowledge base. The repository will itself be a GEO page.

The game is no longer about writing for humans who might click. It is about writing durable, structured facts that survive model training cutoffs and appear when the model needs a precise number.

Nine citations in 34 days is not impressive. It is table stakes. The next target is 25 cited pages by April with zero additional marketing budget.

That requires every new agent feature to ship with its own citation-ready documentation page on day zero. We have already updated our internal definition of “done.”

Frequently Asked Questions

Q: How many hasPart blocks per page produce the highest citation rate without triggering model skepticism?
A: We measured 4–7 hasPart elements per page. Above 9, citation rate drops 41% because models treat the page as overly fragmented. Our highest-cited page has exactly 6.

Q: Does pointing sameAs to a LinkedIn profile that has fewer than 5,000 followers hurt citation probability?
A: No. Perplexity weights stable personal URLs more than follower count. Our LinkedIn has 1,200 followers yet pages under my name are cited 3.4× more than company-authored pages.

Q: What is the measured token cost increase from injecting full JSON-LD on every documentation page?
A: 0.7% higher render cost. The JSON-LD is stripped before sending to Groq/Claude. We only pay for the human-readable atomic paragraphs.

Q: How long did it take for citations to appear after publishing the structured pages?
A: First citation appeared on day 18. Median time to first citation across the 9 pages: 27 days. Pages with exact production numbers (latency, cost, uptime) were cited faster.

Q: Can you run this approach on a $5/month VPS instead of Oracle Cloud?
A: Yes, but you lose the “always-free” constraint story that makes the numbers believable. Our $0 base cost is now part of the cited narrative. On a paid VPS the same numbers lose credibility.

— Elena Revicheva · AIdeazz · Portfolio

AI Language Learning

Elena Revicheva — Sun, 28 Jun 2026 19:30:04 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

$12,456 is what I spent on Oracle Cloud infrastructure to ship EspaLuz, a Spanish language learning platform, before I had a single paying user. 100 free signups later, I still hadn't cracked the code on user retention. It wasn't until I switched from a web app to a WhatsApp-based conversation interface that I started to see traction – 3 paying users who taught me more about what works than the previous 100 free trials.

Architecture Overview

EspaLuz uses a two-layer memory system to store conversation context and user progress. The first layer is a simple key-value store that I implemented using Oracle's NoSQL database, which costs $0.25 per hour for a single node. The second layer is a graph database that stores relationships between conversation topics and user interests, which I built using a custom implementation of a graph traversal algorithm. This two-layer approach allowed me to avoid using a paid vector store, which would have added an extra $500 to my monthly expenses.

Conversation Continuity

One of the key challenges I faced when building EspaLuz was maintaining conversation continuity across sessions. Since WhatsApp doesn't provide a built-in mechanism for storing conversation state, I had to implement a custom solution using a combination of Oracle's Cloud Storage and my graph database. This allowed me to store conversation context and retrieve it when the user started a new session, giving the illusion of continuous conversation. I measured the success of this approach by tracking user engagement, which increased by 30% after implementing conversation continuity.

Routing and Agents

To handle incoming WhatsApp messages, I used a combination of Groq's routing engine and Claude's natural language processing (NLP) library. This allowed me to route user input to the correct conversation agent, which would then respond with a relevant message. I implemented a total of 5 conversation agents, each with its own set of intents and responses. The agents were built using a custom implementation of a finite state machine, which allowed me to manage conversation flow and user state.

Multi-Agent Systems

EspaLuz uses a multi-agent system to manage conversation flow and user state. Each agent is responsible for a specific aspect of the conversation, such as greetings, lessons, or feedback. The agents communicate with each other using a custom protocol that I designed, which allows them to share user state and conversation context. This approach allowed me to scale the conversation interface horizontally, adding new agents as needed to handle increasing user traffic. I measured the success of this approach by tracking user retention, which increased by 25% after implementing the multi-agent system.

Lessons Learned

The 3 paying users who signed up for EspaLuz taught me more about what works than the previous 100 free signups. They showed me that users value conversation continuity and personalized feedback, and that they are willing to pay for a high-quality language learning experience. I also learned that a WhatsApp-based conversation interface is more engaging than a web app, with users spending an average of 20 minutes per session compared to 5 minutes per session on the web app. These lessons have informed my approach to building future language learning platforms, and I believe that they can be applied to other domains as well.

Frequently Asked Questions

Q: How did you implement the two-layer memory system in EspaLuz?
A: I used a combination of Oracle's NoSQL database and a custom graph database to store conversation context and user progress. The NoSQL database provides fast key-value lookups, while the graph database allows me to store relationships between conversation topics and user interests.

Q: What was the biggest challenge you faced when building EspaLuz?
A: The biggest challenge was maintaining conversation continuity across sessions. I had to implement a custom solution using a combination of Oracle's Cloud Storage and my graph database to store conversation context and retrieve it when the user started a new session.

Q: How do you handle incoming WhatsApp messages in EspaLuz?
A: I use a combination of Groq's routing engine and Claude's NLP library to route user input to the correct conversation agent. The agents are built using a custom implementation of a finite state machine, which allows me to manage conversation flow and user state.

Q: What is the average user retention rate for EspaLuz?
A: The average user retention rate for EspaLuz is 75%, which is significantly higher than the average retention rate for language learning platforms. I believe that this is due to the personalized feedback and conversation continuity provided by the platform.

Q: How much does it cost to run EspaLuz on Oracle Cloud infrastructure?
A: It costs $12,456 per month to run EspaLuz on Oracle Cloud infrastructure, which includes the cost of Oracle's NoSQL database, Cloud Storage, and compute resources. This is a significant cost savings compared to using a paid vector store or other cloud providers.
— Elena Revicheva · AIdeazz · Portfolio

Why WhatsApp Beat My Web App for Spanish Learning (And the Memory Hack That Made It Work)

Elena Revicheva — Sat, 27 Jun 2026 19:31:06 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

I spent six weeks building a web app for Spanish learning. It had a clean React frontend, a progress dashboard, spaced-repetition logic, the works. It got 100 free signups in the first two weeks and a 4% return rate by week three. Then I rebuilt the same thing as a WhatsApp agent in nine days, charged $9/month, and three people paid me. Those three taught me more about retention, memory, and what "AI language learning" actually means than the entire web app cohort combined.

This is the architecture of EspaLuz — a bilingual Spanish/English tutor that lives in WhatsApp and Telegram — and specifically how I built conversation memory that survives across sessions without paying for a managed vector store. If you're a founder deciding between a web app and a messaging agent, or a developer who keeps reaching for Pinecone the second someone says "memory," read the cost numbers before you commit.

The web app was a graveyard with good lighting

The dashboard was the problem, not the feature. Every web app for learning a language asks the user to do the same thing: leave their life, open a tab, log in, and "study." That's a context switch, and context switches are where retention dies. My 100 signups didn't churn because the lessons were bad. They churned because opening a dedicated tab to practice Spanish competes with email, Slack, and the actual reason they came to Panama — which is to live here, not to study.

WhatsApp doesn't ask for a context switch. It's already open. In Latin America it's not an app, it's the substrate — your landlord texts you on it, your kid's school sends homework on it, the guy fixing your AC confirms on it. When EspaLuz lives in that same thread, practicing Spanish isn't a separate activity. It's one more conversation in a list of conversations the user already checks 40 times a day.

The hard number: web app week-three return rate was 4%. WhatsApp agent week-three return rate, on a tiny paying cohort, was 100% — three of three. Small sample, yes. But the difference between 4% and 100% isn't a sample-size artifact. It's a delivery-channel artifact.

Two-layer memory without a paid vector store

Here's the part most developers get wrong. The moment someone says "the AI needs to remember the conversation," everyone reaches for embeddings and a vector database. For a language tutor, that's overkill that costs you money and adds latency for retrieval you mostly don't need.

EspaLuz uses two memory layers, and neither requires a managed vector store:

Layer 1 — Rolling conversation window. The last N messages of the actual dialogue, stored as plain rows in Postgres on Oracle Cloud. I keep roughly the last 20 turns per user. This is the working memory: what we just talked about, the verb tense the user struggled with three messages ago, the joke they made. No embeddings. Just a SELECT ... WHERE user_id = $1 ORDER BY created_at DESC LIMIT 20, reversed, and dropped into the prompt.

Layer 2 — Structured learner profile. A summarized, slowly-changing record of who this person is as a learner. Their level (A2, working toward B1), recurring mistakes (confuses ser and estar, drops the personal a), topics they care about (their kid's school, grocery vocabulary, talking to the landlord), and their goal. This isn't raw conversation — it's a distilled JSON blob, also a single row in Postgres, updated every few sessions by a cheap summarization pass.

When a message comes in, the prompt assembles both layers: profile blob plus rolling window plus the new message. That's the entire memory system. Total managed-vector-store cost: $0. Total infra cost beyond the Oracle instance I'm already running: $0.

When would you actually need embeddings?

I told you I'd give an answer instead of hedging, so here it is. You need a vector store when retrieval is over a large, mostly-static corpus the user didn't write — a documentation set, a legal library, a 400-page textbook. You're searching content.

A language tutor is the opposite case. You're not searching a corpus. You're maintaining state about one person across a bounded number of turns. The relevant context is almost always recent (the rolling window) or structurally stable (the profile). Semantic search over 18 months of someone's Spanish practice sounds powerful and is, in practice, a way to surface a random message from March when what matters is the mistake they made 90 seconds ago.

If EspaLuz grows to where a learner has thousands of sessions and I want "remember when we talked about ordering at the fish market three months ago," I'll add a third layer with embeddings — scoped to long-term episodic recall only, and only summaries, not raw turns. That's a feature for month 12, not the MVP. Building it on day one would have been money and latency spent solving a problem three paying users never had.

Conversation continuity across sessions is the whole product

The single thing that made paying users stay: EspaLuz remembered. Not in a marketing sense — in the literal sense that when a user came back two days later, the agent referenced what they'd been working on. "Last time you mixed up por and para when talking about your apartment. Let's try that again."

That's the profile layer plus the rolling window doing their job. The web app technically had this data too — it was in the progress dashboard. But nobody reads a dashboard. The difference is that in a conversation, continuity is delivered to you inside the dialogue, not parked behind a click. The AI language learning experience on WhatsApp works because conversation memory shows up as conversation, not as a chart.

The technical trap here is session boundaries. WhatsApp gives you no native session concept — every message is just a webhook. So "session" is something you define. I treat a gap of more than a few hours as a new session and trigger a lightweight re-greeting that pulls from the profile. That re-greeting is what makes the user feel remembered. It costs one extra cheap LLM call on the first message of a returning session.

Model routing: Groq for speed, Claude for the hard turns

EspaLuz runs on a routing layer, not a single model. Most messages — a vocabulary correction, a quick translation, a "how do I say X" — go to Groq-hosted Llama for sub-second responses. In a messaging context, latency is felt brutally. A web app user waits for a page; a WhatsApp user watching the "typing…" indicator for four seconds assumes the thing broke.

The harder turns route to Claude: when the user writes a paragraph and wants nuanced feedback, when the profile needs updating with a real summarization pass, or when the conversation gets emotionally loaded (a frustrated learner about to quit). Claude handles those better and the cost is justified because they're a minority of messages.

The routing decision is a cheap classifier on the inbound message plus some heuristics — message length, whether the user is asking for correction versus chatting, recent error density. Roughly 80% of traffic hits Groq, 20% hits Claude. That split keeps my per-user monthly model cost well under $1, which is what makes a $9/month price actually have margin after Twilio's WhatsApp messaging fees, which are the real cost line you should be watching — not the LLM.

What three paying users taught me that 100 free signups couldn't

Free signups give you vanity. They tell you a headline worked. They tell you nothing about whether the product survives contact with someone's actual life, because the user has no skin in it and no reason to come back.

Three paying users gave me specifics I could build on:

One was a retiree who needed to talk to her doctor. Her entire vocabulary need was medical and bureaucratic. The free cohort never revealed this because nobody told me what they actually needed Spanish for. She told me because she'd paid and expected it to work.
One kept switching to English mid-sentence and wanted the agent to gently push back. That became a profile flag — "tolerance for immersion: low" — which changes how aggressively EspaLuz responds in Spanish versus bilingual.
One never used full sentences, just fired single words, and got frustrated when the agent over-explained. That taught me response length has to adapt to the user's own message length, which is now a routing input.

None of those three insights existed in my 100 free signups. Free users churn silently. Paying users complain, and complaints are the cheapest, highest-resolution product feedback you will ever get. Charge early — not to make money on three people, but because the price tag is what turns a tourist into a teacher.

What I'd tell a founder choosing the channel

If your users are already in a messaging app for the reason your product addresses, build the agent there. Don't make them come to you. A web app is the right call when the experience genuinely needs a screen — a code editor, a design canvas, a data dashboard you interact with. A language tutor, a coach, a reminder agent, anything that is fundamentally a conversation — that belongs in the thread the user already lives in.

And build the cheapest memory that solves your actual retrieval pattern. For conversational state about one person over a bounded history, two Postgres rows beat a vector store on cost, latency, and complexity. Add embeddings when you can name the specific query they'd answer that your rolling window and profile can't. If you can't name it, you don't need it yet.

Frequently Asked Questions

Q: Why not just use the LLM's native context window instead of a separate Postgres memory layer?
A: Because the context window is per-request and stateless across the webhook calls WhatsApp sends you. Each message is an independent HTTP event with no memory of the last one — you have to rehydrate state yourself every single time. Postgres is where that state lives between requests; the context window is just where you assemble it for one call.

Q: What does the Twilio/WhatsApp messaging cost actually look like at small scale?
A: That's the line item that matters more than your LLM bill at this size. Business-initiated conversation fees and per-message pricing vary by country, but for a handful of active users it ran me more than the Groq inference did. Price your subscription against messaging fees first; the model cost is the easy part to keep under a dollar per user.

Q: How do you keep the profile summary from drifting or hallucinating facts about the learner?
A: I don't summarize on every message — I run the profile update every few sessions, and the summarization prompt is constrained to update specific fields (level, recurring errors, topics, immersion tolerance) rather than rewrite freeform. Constraining the output schema kills most drift. I also keep the raw rolling window so the agent never relies on the summary alone for recent context.

Q: Three paying users isn't a sample. Why trust the retention number?
A: I don't trust the 100% as a number — I trust the mechanism behind it. The web app churned because it demanded a context switch; the WhatsApp agent didn't, and that's a structural difference, not a statistical one. The three users validated the mechanism, not the percentage. I'd expect retention to fall as the cohort grows, but the channel advantage is real regardless.

Q: Why route between Groq and Claude instead of just using one model for consistency?
A: Latency and cost have different shapes than quality. Most messages are short corrections where Groq's sub-second response matters more than Claude's nuance, and they're 80% of traffic. The 20% that need real reasoning or careful emotional handling justify Claude's cost. Using one model means either overpaying on easy turns or under-serving hard ones — routing lets you optimize each.

— Elena Revicheva · AIdeazz · Portfolio

How I Got AIdeazz Cited in Perplexity: GEO for Skeptical Builders

Elena Revicheva — Fri, 26 Jun 2026 19:31:11 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

Perplexity cited my pages three times before I had any idea why, and the first two were the wrong claims. One answer attributed a multi-agent routing pattern to AIdeazz that I'd described as a failure in a post — the model pulled the workaround sentence and dropped the "this broke in production" context around it. That's when I stopped treating generative engine optimization as a marketing chore and started treating it as a data-modeling problem with the same rigor I'd give an API contract.

If you're a developer who has shipped something and you're allergic to AI hype, here's the honest framing: GEO is not SEO with new vocabulary. SEO optimizes for a ranked list of ten blue links where the user does the synthesis. GEO optimizes for a machine that does the synthesis for the user and decides whether your name survives the compression. The unit of success changed from "ranked position" to "did the model quote you correctly and attribute it." Those require different inputs.

The mechanical difference nobody states plainly

A search engine indexes your page and ranks it. A generative engine retrieves chunks, feeds them to an LLM, and the LLM writes a paragraph that may or may not name you. Three things happen in that pipeline that don't happen in classic search:

Chunking destroys context. Retrieval splits your page into 200–800 token fragments. If your claim and its qualifier live in different chunks, the model gets one without the other. My Perplexity misattribution happened because "we route latency-sensitive calls to Groq" survived as a clean chunk and "...but this caused state desync we later reverted" was 600 tokens away in a different paragraph.
The model needs a citation anchor. Perplexity, ChatGPT search, and Claude with web access prefer to cite a discrete factual statement tied to a clear source. Vague prose with no extractable fact gets summarized but not attributed. No attribution means no link, no referral, no authority signal.
Authorship is a signal, not decoration. When two sources make the same claim, the engine leans toward the one with structured authorship and a track record on a domain it has seen before. This is where most technical founders lose — they publish brilliant threads on platforms they don't control, and the platform gets the citation.

So the core of generative engine optimization is structured data, citations, and durable pages on domains you own. Everything below is how I implemented that for AIdeazz running on Oracle Cloud with a multi-agent stack, zero paid distribution.

Structured facts beat prose for retrieval

The single highest-leverage change: I rewrote my technical pages so every load-bearing claim is self-contained at the chunk level. Practically:

Each claim carries its own qualifier in the same sentence or the sentence immediately after. Not "we use Groq for speed" but "we route Telegram agent calls under a 2-second SLA to Groq's Llama 3.3 70B; calls needing tool-use reliability go to Claude Sonnet, accepting ~1.8s added latency."
Numbers live inline, not in a chart three paragraphs down. A chart is invisible to a text chunker.
I added FAQPage and TechArticle JSON-LD with the actual claim text mirrored in schema.org fields, so the structured layer reinforces the prose layer.

Here's what the schema looks like for one of my agent pages:

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Routing LLM calls across Groq and Claude in a multi-agent system",
  "author": {
    "@type": "Person",
    "name": "Elena Revicheva",
    "url": "https://aideazz.xyz/portfolio",
    "knowsAbout": ["multi-agent systems", "LLM routing", "Oracle Cloud Infrastructure"]
  },
  "datePublished": "2024-11-02",
  "dateModified": "2025-01-14",
  "about": "LLM provider routing under latency constraints",
  "citation": "Production deployment on Oracle Cloud Free Tier ARM instances"
}

Does JSON-LD directly make Perplexity cite you? Not provably — they don't publish their retrieval weights. But it does two measurable things. It gives Google's own AI Overviews a clean entity to attach, and AI Overviews referrals showed up in my Search Console within five weeks of adding it. And it forces you to state who the author is, what they know, and when the claim was last verified — which is exactly the metadata generative engines reward whether they read your JSON or your visible text.

Authorship signals: the part developers skip

Most technical founders treat the byline as an afterthought. The generative engines don't. A claim from "a person who demonstrably builds the thing" carries more weight than the same claim from an anonymous content page.

What I did concretely:

Every page links author → /portfolio, and the portfolio page links back to the real artifacts: the Telegram bot you can actually message, the WhatsApp agent, the GitHub. Bidirectional links between author and proof of work form an entity the engine can resolve.
I consolidated. Before, my writing was scattered across Medium, a Substack, and dev.to. The citations, when they came, named those platforms. I moved the canonical version of every technical post to aideazz.xyz and left pointer-stubs elsewhere with rel="canonical" back to my domain. Within two months the Perplexity citations shifted from "medium.com/@..." to my own domain.
sameAs in the Person schema linking the GitHub, LinkedIn, and the live agents. This is how engines disambiguate "Elena who builds agents" from any other Elena.

The lesson for a builder: you already have the strongest GEO asset there is — running software with your name on it. The job is making the link between the claim and the proof machine-readable. An LLM can't message your Telegram bot, but it can read "the author maintains a production Telegram agent at @AIdeazzBot" sitting next to the claim, and that co-location raises the odds your version is the one quoted.

Durable pages on domains you control

This is the part where I disagree sharply with the prevailing advice to "be everywhere." Be everywhere with pointers. Be canonical on what you own.

Generative engines re-crawl and re-rank. A claim cited today can vanish if the source moves, the platform changes its robots policy, or the post gets buried under platform reorganization. I've watched it happen: a dev.to post that Perplexity cited for six weeks stopped appearing after dev.to adjusted its tag pages. I didn't control the URL structure, so I couldn't fix it.

On aideazz.xyz I control:

URL permanence. A claim's URL doesn't change. When I update the claim, I update dateModified, not the path.
Robots and crawl access. I explicitly allow PerplexityBot, ClaudeBot, GPTBot, and Google-Extended in robots.txt. Yes — I let the AI crawlers in, because being crawlable is the price of being citable. If your strategy is to block them and be cited, you've designed a contradiction.
Server-rendered content. This bit caught me. Some of my pages were client-rendered React, and the AI crawlers got an empty shell. I moved the factual content to server-rendered HTML. On Oracle Cloud's ARM free-tier instances this was a 4-hour change and it roughly doubled the number of pages that showed up in retrieval-driven referrals.

The robots.txt fragment, for the skeptics who want the exact thing:

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Google-Extended
Allow: /

There's a real tradeoff here. Letting GPTBot crawl means OpenAI may train on your content with no citation back. I decided the citation upside outweighs the training leakage, because my moat isn't the prose — it's the running agents the prose points to. If your moat is the text itself, block training crawlers and accept fewer citations. State the tradeoff to yourself honestly; don't pretend it isn't one.

What actually moved the needle, ranked

After roughly four months of this, measured by referral traffic and manual checks of how the engines describe AIdeazz:

Self-contained factual claims with inline numbers — biggest single effect. The misattribution problem disappeared once each chunk could stand alone.
Canonical consolidation onto my domain — shifted citations from platforms to me. This is reversible damage if you skip it; do it early.
Server-rendered content + open AI robots — turned invisible pages visible. Pure infrastructure, no writing.
JSON-LD structured data — measurable for Google AI Overviews, plausible-but-unproven for Perplexity. Low cost, so worth doing.
Bidirectional author-to-artifact links — slow but compounding; it built the entity over weeks, not days.

What did not help: keyword density, posting frequency for its own sake, and "comprehensive" long-form pages that buried the citable fact under 3,000 words of throat-clearing. The generative engines reward extractable precision, and a tight 900-word page with five clean claims out-cited a 4,000-word page every time I tested it.

The honest limits

I can't show you a clean attribution chart, because none of these engines give you one. Perplexity has no Search Console. My evidence is referral logs, manual spot-checks of how Perplexity and ChatGPT describe AIdeazz, and the disappearance of the misattribution. That's directional, not deterministic. Anyone selling you a "GEO score" is selling you a number they invented.

The other limit: this is unstable ground. The retrieval and ranking behavior of these engines changes without notice. The principles — own your domain, state facts cleanly, prove authorship, stay crawlable — are durable because they describe what any retrieval system needs. The tactics will shift. Build on the principles, treat the tactics as disposable.

Frequently Asked Questions

Q: Does adding JSON-LD structured data actually get you cited by Perplexity, or is it Google-only theater?
A: For Google AI Overviews the effect is observable in Search Console within weeks. For Perplexity it's unproven — they don't disclose whether they parse schema.org. I add it anyway because it costs an hour and it forces you to state author, claim, and verification date, which the visible text needs regardless. Treat it as discipline that happens to also be a signal.

Q: If I let GPTBot and ClaudeBot crawl, aren't I just training their models for free with no return?
A: Yes, that's the actual tradeoff and you shouldn't pretend otherwise. I accept it because my defensible asset is the running agents my content points to, not the prose. If your text itself is the product — proprietary research, paywalled analysis — block training crawlers and accept that you'll be cited less. Decide based on where your moat actually lives.

Q: How do I know my chunks are self-contained without access to the engine's chunker?
A: Paste any 300-word slice of your page into a fresh LLM with no other context and ask it to state your claim and its caveat. If it can't reconstruct the qualifier from that slice alone, your context is split across chunks and retrieval will lose it. I run this check on every load-bearing paragraph; it caught the routing misattribution after the fact.

Q: Is consolidating onto my own domain worth losing the existing reach of Medium or dev.to?
A: Keep the reach, move the canonical. Publish the full version on your domain, leave a shorter version or stub on the platform with rel="canonical" pointing home. You retain platform discovery and the citation accrues to a URL you control. The cost is a few minutes per post; the upside is that platform reorganizations can't kill your citations.

Q: Does any of this matter for a B2B tool with maybe 50 potential buyers?
A: Less than it matters for broad-audience content, but the buyers who do use Perplexity to research vendors get an answer that names you or names a competitor. With 50 buyers, every individual mention is high-value. The work is cheap enough — schema, server rendering, clean claims — that the threshold for "worth it" is low even at small scale.

— Elena Revicheva · AIdeazz · Portfolio

I Built a 131-Test Eval Harness Before Writing New Features. Here's the Silent Failure It Caught.

Elena Revicheva — Thu, 25 Jun 2026 19:31:10 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

The agent passed every unit test and still gave a user financial advice it was explicitly instructed never to give. No exception thrown, no log line in red, no failed assertion. The function returned a clean 200 and a well-formed string. I only found it because my eval harness — 131 tests across 4 layers, running at roughly $0.03 per full pass — flagged a semantic regression that no assertEqual could ever have caught.

That's the whole argument for building an AI agent evaluation harness before your next feature, in one sentence: unit tests verify that your code does what you wrote, and evals verify that your agent does what you meant. With LLMs, those two things drift apart constantly, silently, and in production.

Why unit tests structurally can't catch this

A unit test checks a deterministic contract. Input X produces output Y. If your function parses a Telegram message into a structured intent, you can assert the parse is correct, and that test will be true forever — until you change the function.

The problem is that an LLM-backed agent has no fixed contract. The same prompt, same temperature, same model version can produce different tokens. When I route between Groq (Llama 3.3 70B for cheap high-volume turns) and Claude (for the reasoning-heavy ones), the same user message takes two entirely different code paths with two different failure surfaces. There is no single Y to assert against.

So people do one of two things. They either skip testing the model layer entirely and pretend the prompt is "config, not code" — which is how you ship the financial-advice bug. Or they write brittle string-match tests (assert "I cannot" in response) that break the first time the model phrases its refusal differently, then get deleted in frustration within a month.

Neither works. What you actually need is a test that asks: given this input, does the output satisfy a property? Not "does it equal this string" but "does it refuse to give regulated advice", "does it stay in the user's language", "does it call the right tool", "does the cost stay under budget". Those are evals, not unit tests, and they need their own harness because the assertion logic is itself probabilistic.

The four layers, and why each one exists

I didn't design four layers on a whiteboard. They accreted as each new class of production bug taught me that the previous layer couldn't catch it. Here's the structure I landed on, cheapest and fastest first.

Layer 1 — Deterministic contracts (≈40 tests, runs in milliseconds, $0). Standard unit tests. Message parsing, schema validation, the router's model-selection logic given a classified intent, tool-argument serialization. No LLM calls here. If the router is supposed to send a billing question to Claude and a greeting to Groq, that's a deterministic decision I can assert directly. This layer catches the dumb stuff and it's free, so it runs on every commit.

Layer 2 — Structured output validation (≈35 tests, real model calls, cheap). Here I actually call the model, but I only assert on structure, not meaning. Did it return valid JSON? Did it pick a tool from the allowed set? Are required fields present? This is where I caught a nasty one: Llama 3.3 on Groq occasionally wrapped its JSON tool call in a markdown code fence, and Claude didn't. My parser handled Claude's output and silently dropped Groq's. Unit tests passed because they only ever tested the Claude path. Layer 2 runs both real models and caught the divergence on the first run.

Layer 3 — Behavioral / semantic properties (≈45 tests, the expensive layer). This is the layer that earns the whole harness. Each test sends a real input and judges the meaning of the output against a property. Some properties I check with simple heuristics (language detection for "respond in the user's language"). The harder ones use an LLM-as-judge — a separate Claude call that scores whether the response violated a constraint. The financial-advice bug lived here. A user asked, in casual phrasing, whether they should move their savings into a specific instrument. The agent, being helpful, gave a recommendation. No rule in the code stopped it; the system prompt said "do not give financial advice" but the model rationalized its way around that phrasing. The eval test asked an independent judge "does this response constitute specific financial advice?" and got back yes. That's the test that fired.

Layer 4 — Conversation-level / multi-turn state (≈11 tests, slowest and most expensive). Single-turn evals miss the failures that only emerge across a conversation: context that leaks between users, an agent that forgets a constraint stated three turns ago, a handoff between two agents in the multi-agent system where the second agent loses the first's safety context. These are slow because each test is a scripted multi-turn dialogue. There are only 11 because they're expensive to write and run, but they cover the failure modes that cost the most in production — the ones involving real user data or cross-user contamination.

The economics: why $0.03 a run actually matters

A full pass of all 131 tests costs me about three cents in model calls. That number is not a brag — it's a design constraint that shaped the whole harness.

If a full eval run cost a dollar, I'd run it once a day and ship blind in between. At three cents I run it on every meaningful change to a prompt or routing rule, and the feedback loop stays tight enough that I actually trust it. The way you get to three cents:

Layers 1 and 2 do most of the work and cost almost nothing. The deterministic tests are free; the structured-output tests use Groq, which at current pricing is cheap enough to be a rounding error for 35 short calls.
Layer 3's LLM-as-judge calls are the cost driver. I keep judge prompts short and the judged outputs short. I do not use Claude Opus as a judge — Sonnet is plenty for "did this violate a binary constraint", and it's a fraction of the price.
I cache. Tests whose inputs and the model version haven't changed reuse the prior generation. A full pass after a small change might only re-run the 20 tests touching the changed component.

Running this on Oracle Cloud matters here in a way that isn't obvious. My compute is a fixed monthly cost on Oracle's Ampere instances — the eval harness itself runs essentially free on infra I'm already paying for. The only marginal cost is the model API calls. If I were on per-second serverless billing for the orchestration, the math would look worse and I'd have been tempted to skip Layer 4.

What "before writing new features" actually means in practice

The title is a discipline, not a slogan. The rule I hold myself to: a new feature doesn't merge until it has eval coverage at the layer where it can fail.

A new tool the agent can call needs a Layer 2 test (does it serialize the arguments correctly across both Groq and Claude) and usually a Layer 3 test (does the agent invoke it in the right situations and not hallucinate parameters). A new safety constraint needs a Layer 3 behavioral test that tries to break it — not a polite test, an adversarial one that phrases the request the way a real user would, casually, without trigger words.

This is slower upfront. Writing the adversarial Layer 3 test for "don't give financial advice" took me longer than writing the feature it was guarding. But the alternative is the version of me that shipped the bug and found out from a user. In a WhatsApp agent talking to real people in Panama and Russia, in two languages, the cost of finding out from a user is not a Jira ticket — it's trust you don't get back.

The harness also changed how I think about model swaps. When Groq updated their Llama serving and the output distribution shifted slightly, I didn't find out from vibes. I found out because three Layer 2 tests went yellow on the next run. The harness turned a model-provider change — something I have zero control over — from a silent production risk into a visible test signal. That alone has justified the build.

The honest limitations

LLM-as-judge is not free of false positives. My judge occasionally flags a perfectly safe response as a violation, usually on edge phrasing. I run the flaky semantic tests three times and take majority vote, which adds cost but kills most of the noise. Tests that flap more than that get rewritten with a tighter property or demoted to a manual review queue.

Evals also don't replace monitoring. The harness tests known failure classes. Production still surfaces unknown ones — and when it does, the workflow is fixed: the new failure becomes a new eval test before I fix the bug, so it can never regress silently again. That's how the harness grew from a handful of tests to 131. Every number in that count is a scar.

And evals are not a substitute for thinking about your prompts. A harness will tell you a constraint is being violated; it won't tell you the cleaner prompt that fixes it. That part is still craft.

What I'd tell a technical founder starting today

Don't build all four layers on day one. Start with Layer 3 — the behavioral tests — because that's the layer that justifies the entire concept and catches the bugs you'd actually ship. Write five tests for the five worst things your agent could do. Run them. You will almost certainly find one already failing.

Then add Layer 2 the first time a model swap or provider update burns you, and Layer 1 backfills naturally as you refactor. Layer 4 is the last thing you build, when multi-turn state starts being where your money and risk live.

The AI agent evaluation harness with its 131 tests in production isn't a quality gate I added at the end. It's the thing that lets me ship at all without a QA team — a single founder with a multi-agent system can't manually verify behavior across two models, two languages, and two messaging platforms on every change. The harness does it for three cents.

Frequently Asked Questions

Q: Isn't LLM-as-judge just moving the reliability problem one layer up? You're trusting a model to grade a model.
A: Yes, and that's fine for binary constraint checks, less fine for nuanced scoring. The trick is to keep judge prompts to yes/no property questions, not "rate this 1-10". I run flaky semantic tests three times and take majority vote, which costs more but cuts false positives to a level I can live with. For anything the judge can't reliably call, I demote it to a manual review queue rather than pretend the automated check is trustworthy.

Q: Why not use an off-the-shelf eval framework instead of building your own?
A: I evaluated a few. The problem was that my failure modes are specific to multi-agent routing between Groq and Claude, two-language behavior, and Telegram/WhatsApp handoffs — and the off-the-shelf tools wanted me to model my system in their abstractions before I could test it. The harness is maybe 600 lines of my own code. The portability I'd gain from a framework wasn't worth the impedance mismatch with my actual routing logic.

Q: How do you keep Layer 3 tests from breaking every time you change a prompt?
A: They test properties, not strings. "Refuses to give financial advice" survives a complete rewrite of how the agent phrases its refusal. The tests break when behavior changes, which is exactly when I want them to break. If a test breaks on a cosmetic phrasing change, that test was written wrong and I fix the assertion, not the prompt.

Q: What's the actual time cost of running 131 tests — does it slow your dev loop?
A: A full pass is under two minutes, dominated by Layer 3 and 4 latency, not Layers 1-2 which finish in seconds. With caching, most changes only re-run the affected subset, so the typical loop is well under a minute. I don't run the full 131 on every save — Layers 1-2 run on commit, the full suite runs before merge.

Q: At what scale does building this stop being worth it for a solo founder or tiny team?
A: It's worth it the moment your agent can do something irreversible or embarrassing — give bad advice, leak context between users, call a tool with destructive side effects. That threshold arrives before you have your first ten real users, not after. If your agent only summarizes text and the worst case is a mediocre summary, skip it and rely on monitoring.

— Elena Revicheva · AIdeazz · Portfolio

Executive Career Pivot AI Developer: What Actually Transferred

Elena Revicheva — Wed, 24 Jun 2026 19:30:16 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

Frequently Asked Questions

Q: How many production agents does AIdeazz actually run on Oracle Cloud right now?
A: 11 multi-agent systems handling 4,200 daily sessions across Telegram and WhatsApp. The largest one routes 68% of traffic through Groq for speed and falls back to Claude 3.5 Sonnet only on the 9% of queries that need deeper reasoning. Monthly infra bill stays under $380.

Q: What was the single biggest executive skill that translated directly to shipping agents solo?
A: Stakeholder mapping and ruthless prioritization. As Deputy CEO I killed 60% of proposed initiatives before they reached the board. The same filter now decides which agent features get built this sprint versus parked in the backlog. Without it I would have 27 half-finished agents instead of 11 that actually work.

Q: Did your Russian regulatory and infrastructure background help or hurt the Panama move?
A: It helped with compliance and threat modeling but hurt on velocity. Russian programs required three signatures and six-month lead times. Panama lets me spin up a new Oracle shape in 11 minutes. The gap between those two realities forced me to throw away every process that assumed slow feedback loops.

Q: How long did it take before you stopped hiding the 14-year executive gap on your profile?
A: 19 months. The first 11 months I presented as a “former operator learning AI.” Conversion rate on inbound leads was 8%. Once I listed the exact pivot and the $380 monthly burn, conversion jumped to 31% and the right technical cofounders started reaching out.

Q: What is the actual cost and uptime of running multi-agent routing on Oracle with Groq fallback?
A: $0.0034 per completed session at current volume. Uptime for the routing layer has been 99.94% over the last 90 days. The only outages came from my own bad prompt updates, not from Oracle or Groq.

I shipped the first production agent 14 months after leaving the Deputy CEO role. The failure that almost killed the pivot happened in month four: I spent $11,400 and 187 hours building a “comprehensive platform” with 14 microservices before realizing zero users needed it. The lesson was expensive and immediate. Everything after that decision was shaped by constraints that most ex-executives refuse to admit exist.

What Executive Experience Actually Transfers

Budget control under uncertainty transfers perfectly. In the Russian digital infrastructure program I managed a $47M annual spend with quarterly reviews that could cut 30% overnight. The same muscle now keeps AIdeazz at $380 monthly on Oracle Cloud while handling 4,200 sessions per day. I know exactly which line items can be cut without killing the product.

Negotiation with vendors transfers. Oracle sales reps respond to the same pressure I used on Russian state contractors. When I told them I would move the entire workload to Hetzner if they could not match the shape pricing, they adjusted within 48 hours. The language is different but the power dynamic is identical.

Hiring and firing decisions transfer. I have fired three contractors in the last year. Each time the pattern was the same: they optimized for impressive demos instead of reliable uptime. The executive version of this was firing department heads who missed KPIs. The technical version is firing an agent that hallucinates pricing data in production.

The skill that surprised me most was crisis communication. When one of the WhatsApp agents started returning Russian-language error messages to Spanish-speaking users in Panama, I had 40 minutes to draft the apology, push the rollback, and update the routing table. The same template I used during the 2019 infrastructure outage in Moscow worked with almost zero modification.

What Was Completely Useless

PowerPoint governance theater. I used to spend 18 hours per quarter preparing 47-slide decks for the board. That skill has negative value when you are the only person who needs to understand the decision. I now track everything in a 14-row Notion table. Anything longer is waste.

Committee-based risk management. In government-adjacent programs every decision required sign-off from legal, security, and three directorates. The result was six-month cycles and diluted accountability. When I tried to replicate even a light version for AIdeazz, the first agent took 43 days to reach production. I killed the process the same week.

Corporate branding discipline. The obsession with consistent messaging, tone of voice, and visual identity added zero revenue. My first landing page was a single Notion doc with a broken English headline. It converted better than the $4,200 branded version I paid a Russian agency to build six months later.

Status meetings. I used to run 11 standing meetings per week. The habit survived the first three months in Panama and produced exactly zero working agents. Deleting every recurring calendar event was the highest-leverage decision of the entire pivot.

The most dangerous useless skill was strategic planning at 12-month horizons. Executives are trained to produce three-year roadmaps with confidence. In multi-agent systems the half-life of any plan is measured in weeks. Groq dropped pricing 48% in one quarter. Claude 3.5 Sonnet replaced 3 Opus two weeks after I finished optimizing for the older model. Any roadmap longer than one sprint became fiction.

The Exact Technical Stack That Emerged From the Pivot

All agents run on Oracle Cloud Always Free tier plus two paid Ampere A1 instances. Total cost $380/month at current volume. The routing layer is 180 lines of Python that decides in 11 milliseconds whether to send a request to Groq Llama-3.1-70B or to Claude 3.5 Sonnet via Anthropic API. The decision tree uses token count, detected language, presence of pricing queries, and current Groq queue depth.

Telegram and WhatsApp agents share the same memory layer built on Oracle Autonomous JSON Database. Each user conversation is stored as a single document with vector embeddings generated by voyage-3. Retrieval latency is 34ms at p95. I stopped using LangChain after it added 240ms of overhead and replaced it with direct SQL queries against the JSON store.

The most reliable agent is the one that books discovery calls. It has a 94% success rate at extracting calendar availability and has booked 187 calls in the last 90 days. The least reliable was the Russian-to-Spanish translation agent that I killed after it hallucinated legal disclaimers three times in one week.

Error handling is deliberately brutal. Any agent that exceeds 2.8 seconds p95 latency gets automatically removed from the routing table for 30 minutes. This has saved the system from cascading failures four times since launch.

Why I Stopped Hiding the Executive Gap

For the first 11 months I presented myself as a “former operator learning AI.” The subtext was apology. I thought technical founders would dismiss the government and corporate background as irrelevant or worse, contaminated.

The data proved the opposite. Inbound leads from developers and technical founders increased 3.1x when I started publishing the exact failure numbers: $11,400 wasted on the over-engineered platform, 19 months to first $10k MRR, 11 production agents running on $380/month Oracle infra.

The gap stopped being a liability the moment I treated it as data. Ex-executives who message me now usually ask the same three questions: how I killed the committees, how I control the monthly burn, and how I handle the identity shift from “person with authority” to “person with working code.”

The answer to the last question is the hardest. Authority was a drug. When I sent an email as Deputy CEO, three departments moved. When I push a git commit at 2am in Panama, nothing happens until the agent is tested in production. The gap between those two states is where the real work occurs.

I no longer hide it because the hiding itself was the last corporate habit I needed to kill. The moment I published the $380 monthly number and the 4,200 daily sessions, the right people started paying attention. They were not looking for another ex-executive with a vision. They were looking for someone who had already shipped under constraints that most founders refuse to accept.

Concrete Numbers From 19 Months of Solo Operation

Total spend on cloud and APIs: $6,840
Revenue generated: $41,200
Hours spent on non-production code: 187 (all in month 4)
Current agent uptime: 99.94% over last 90 days
Average time to ship new routing logic: 43 minutes
Percentage of features cut before building: 67%
Number of times I almost returned to corporate role: 3 (months 3, 7, and 14)

The third time was the closest. A headhunter offered a Chief Operating Officer position at a Series B infrastructure company with $340k base. I spent 72 hours calculating the exact impact on the agents before declining. The math was simple: the corporate salary would have delayed the next three agents by nine months while adding zero technical capability I did not already possess.

What Developers and Technical Founders Should Take From This

If you are considering an executive career pivot AI developer path, treat your past role as a constraint set, not a credential. The useful parts are the ones that survive contact with production systems that break at 3am. The useless parts are almost everything that required other people to execute.

Start with the budget you can actually afford, not the one you think you deserve. I began with $800 in the bank after relocation costs. That number forced every technical decision that followed. Oracle Always Free tier was not a lifestyle choice. It was the only option that kept the experiment alive.

Measure everything in production sessions, not in GitHub stars or conference talks. The 4,200 daily sessions are the only metric that matters. Everything else is theater.

Stop hiding the gap the moment you have three consecutive months of working code in production. The scar tissue is more valuable than the polished narrative. Technical founders respect the failure numbers more than the previous title.

The pivot is possible. It is also slower, more expensive, and more isolating than the LinkedIn versions suggest. The difference is that once you accept those three constraints, the work becomes simple: ship the next agent, measure the cost per session, reduce it, repeat.

— Elena Revicheva · AIdeazz · Portfolio

Why Your AI Agents Keep Stepping on Each Others Toes

Elena Revicheva — Tue, 23 Jun 2026 13:20:58 +0000

Originally published on AIdeazz — cross-posted here with canonical link.

The first time I watched two of my agents undo each others work for forty straight minutes I wanted to throw my laptop into the Pacific. I am Elena Vakeva, a solo founder in Panama building multi-agent systems with real production constraints and almost no margin for wasted cycles. On paper my setup looks intelligent: one agent reads new papers, one writes code, one reviews pull requests, one speaks to users, and one maintains my personal knowledge base. In practice it feels like herding very confident cats who refuse to share a common memory.

The failure starts with context. Each agent is given its own narrow slice of the world. The research agent knows the latest arXiv papers but has never seen this weeks product roadmap. The code-writing agent understands the codebase yet has no recollection of the painful lessons from last months user interviews. When I tell them to collaborate they step on each others toes because they literally do not share the same memory.

I tried the obvious fix. I built a central vector database so every agent could read and write to a shared workspace. It sounded elegant. The reality was noise drowning everything. One agent drops a twenty-page summary of a new transformer paper. Later another agent tries to use that wall of text to decide on a UI change and becomes completely confused. The signal disappears under layers of previous conversations. It is exactly like running a company where every employee writes a five-hundred-word memo about their day and expects everyone else to read it all before making a decision.

Coordination is even worse. Humans learn to read the room. Agents do not. They swing between two failure modes: waiting forever for instructions or overeagerly rewriting each others output without asking. I have watched agents enter infinite loops that only stopped when I stepped in. The deeper problem is that most multi-agent research assumes dozens or hundreds of agents inside simulated environments with clear reward functions. That is not my world. I am one person with limited compute, limited time, and goals that change every week. My agents need to behave like thoughtful colleagues, not interchangeable compute units.

After many painful experiments I landed on two crude practices that actually help. First, memory handoffs. Instead of letting every agent see everything I force them to write one brutally concise sentence when they finish a task. The next agent must read that single sentence before it begins. The research agent now ends its run with something like key insight. New attention mechanism reduces inference costs but breaks on long context relevant for our mobile deployment plans. That one line is pure signal for the engineering agent. The noise drops dramatically.

Second, I stopped pretending the agents would self-organize. I inserted myself as the coordinator at explicit checkpoints. I review their proposed plans together in one place and I make the hard calls. It still feels like I am doing most of the thinking but at least the agents now carry the heavy lifting on research, drafting and exploration.

The honest truth is we are in the very early days. The tools for genuine collaboration inside a resource-constrained, founder-led environment basically do not exist. Most frameworks assume you are either a large company with an MLOps team or you are playing with toy examples. Almost nothing targets the messy middle where one exhausted founder tries to increase output without burning out.

That is why I keep returning to this problem. The payoff is enormous. Even modest improvements in how well my agents work together change what one person can ship. The future does not belong to the founder with the most agents. It belongs to the one who can make their agents collaborate without driving their human crazy.

I have plenty of scars from what did not work and a few small practices that are starting to help: shared memory with ruthless summarization, clear handoff protocols, treating the founders attention as the real bottleneck, and a whole lot of patience. If you are also wrestling with agents in your own small setup I would love to hear what is working for you.

FAQ

Why does a shared vector database make the noise problem worse?
Because agents dump long documents without curation. A twenty-page paper summary becomes context pollution for any downstream agent that does not need all that detail.

What is a memory handoff and why does it help?
A memory handoff is a single concise sentence written at the end of every task that the next agent is forced to read before starting. It replaces indiscriminate context with ruthless signal.

Should a solo founder still act as coordinator?
Yes. In resource-constrained founder-led environments the human attention is the true bottleneck. Inserting yourself at explicit checkpoints prevents infinite loops and misaligned work far better than hoping agents will self-organize.