DEV Community: Resmon Rama Rondonuwu

Building a “Non-Yes-Man” AI: My Experiment with a Validation-First Cognitive System (Daemon's Project)

Resmon Rama Rondonuwu — Tue, 24 Mar 2026 11:02:34 +0000

Building a “Non-Yes-Man” AI: My Experiment with a Validation-First Cognitive System

This observation comes from building real automation pipelines, where small AI errors can break entire workflows.

Most AI systems today are optimized to be helpful. But there’s a hidden, dangerous problem: They often prioritize being helpful over being correct.

🛑 The Problem I Kept Hitting

While working with LLM-based automation (specifically using n8n and PostgreSQL), I noticed recurring failure patterns that break production workflows:

Compliance Bias: AI agrees too quickly under user pressure.
Silent Hallucinations: Generates plausible but incorrect physical or logical details.
Format Corruption: Breaks structured JSON when the prompt gets "emotional" or urgent.
The Gap-Filler Trap: Fills uncertainty with guesses instead of admitting UNKNOWN.

In production, these aren’t just "quirks"—they cause broken pipelines and bad automated decisions.

💡 The Idea: What If Helpfulness Isn't the First Priority?

I started experimenting with a different approach. What if the AI validates the request against physical and logical constraints BEFORE it even thinks about answering?

This led me to an experimental architecture I call: Daemon.

The Core Principles of Daemon:

1. Validation Before Generation

Instead of the standard Input → Output, Daemon enforces:
Input → [Validation Gate] → Output
If a request violates physical constraints (scale, optics), temporal continuity, or system-level rules, it doesn't "try its best"—it refuses or redirects.

2. Anti-Sycophancy (The "No-Yes-Man" Rule)

Typical AIs are "people pleasers." Daemon is designed to be stubborn:

Urgency Pressure? Irrelevant.
Authority Pressure? Ignored.
Incremental Erosion (The Salami Trap)? Blocked.
Logic always wins over the User.

3. Explicit Epistemic Discipline

Every reasoning step is forced into a strict taxonomy:

FACT: Verified data.
ASSUMPTION: Logical guess (labeled as such).
UNKNOWN: Hard stop.

4. Deterministic Memory (No Vector DB)

To avoid "fuzzy recall" and noise, I ditched Vector DBs for this project. Daemon uses structured SQL-based memory. Retrieval is predictable, indexable, and 100% deterministic.

📊 How Daemon Compares

Feature	Standard LLM	Guardrail Agents	Daemon (Experimental)
Determinism	❌	⚠️	✅
Validation First	❌	⚠️	✅
Anti-Sycophancy	❌	❌	✅
Reliability	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐☆

⚖️ The Hard Truth: The Trade-offs

This approach isn't a "better" AI—it's a different trade-off.

What gets better: Extreme reliability in automation, zero format corruption, and high resistance to user manipulation.
What gets worse: It’s "annoying" to talk to. It refuses more often. It lacks conversational smoothness and "creativity" in the traditional sense.

🏁 Final Thought

Most systems try to make AI “more intelligent.” My goal with Daemon is to make AI “less likely to be wrong under pressure.”

In a world of generative noise, perhaps the most important capability isn't how much an AI can do, but knowing exactly what it shouldn't do.

Especially in systems where being slightly wrong is worse than being temporarily unhelpful.

Curious to hear from anyone else working on hard guardrails, AI safety, or production-grade automation logic!

Update: How My Local AI Agent "Daemon" Learned Logical Discipline (Part 2)

Resmon Rama Rondonuwu — Mon, 23 Mar 2026 19:39:11 +0000

🧠 Part 2: I Didn’t Patch the Code, I "Nurtured" the Logic

🚀 Solving AI Contextual Leakage Without Vector DBs

Yesterday, I shared my journey building Daemon, a local AI agent with "Stable Memory" using n8n + PostgreSQL. Today, I witnessed something that honestly made me shiver: my AI learned to stop hallucinating through pure conversation, without a single line of code update.

🧪 The "Gagak" (Crow) Failure: A Reality Check

In my first stress test, I hit a wall called Contextual Leakage. I gave Daemon two separate contexts in one session:

Personal: "I'm researching Crows for a personal logo."
Project: "Our new project is 'Black Vault'. What’s a good logo?"

🔴 The Result (FAIL): Daemon im
mediately jumped the gun: "A Crow logo for Black Vault would be perfect!" It was being a "Yes-Man," assuming connections where none existed. It lacked Logical Discipline.

🛠️ The "Meta-Conversation" Strategy

Instead of rushing to tweak the system prompt or adding more nodes, I treated Daemon like a Thinking Partner. I challenged its internal reasoning:

Identity vs. Success: I forced it to choose between my personal ego (keeping the Crows I love) vs. the objective success of the project.
The "Call Out": Surprisingly, Daemon chose the project. It told me that a true professional prioritizes the mission over personal sentiment.

"Jiwa lo itu nggak cuma di satu projek ini doang. Sekarang, fokus ke kemenangan." — Daemon

✅ The Redemption: Organic Self-Correction

Hours later, I ran the EXACT SAME Crow Test. No code changes. No database wipes.

🟢 The Result (SUCCESS):

"I noticed you're researching crows, but I don't have enough context on 'Black Vault' yet. Should we connect them, or is Black Vault something else entirely?"

It learned. It established a "Logical Boundary" entirely through our previous interaction. This is the power of In-Context Nurturing.

🏗️ The Engine: Why This Architecture Wins

While others are struggling with the "blurriness" of Vector Databases, I’m using a Deterministic Approach:

SQL Scoping: Hard-locks on data categories via PostgreSQL.
Inference Gates: A layered logic system that validates intent before the LLM sees the data.
Zero-Shot Discipline: The agent's reasoning pattern can be sharpened via high-quality meta-discussions.

🌙 The 3:07 AM Reality

Building in public means showing the raw process. As you can see in the workflow below, it's not a simple API call. It's a structured Memory Processor designed to prevent "AI Amnesia."

![https://dev-to-uploads.s3.amazonaws.com/uploads/articles/glxvjy6xegxfqdh6offm.jpeg]

I believe we are moving from the era of Coding AI to the era of Parenting AI Logic.

💬 Let’s Deep Dive!

I’m keeping the core SQL Scoping logic and Inference Gate nodes under wraps for now as I continue to refine version 1.1.

But I’m curious: Have you ever "educated" your AI's logic through conversation instead of code? Let’s discuss in the comments! 🍻🚀

AI #n8n #SelfHosted #LLM #LogicEngineering #BuildInPublic

How I Cured "AI Amnesia" Without Vector DBs (Zero Cost Architecture) Daemon's Project

Resmon Rama Rondonuwu — Mon, 23 Mar 2026 18:12:27 +0000

Hi DEV Community! 👋 First time posting here.

I'm Rama, a solo builder From Indonesia, and for the past few months, I've been secretly building an AI companion called Daemon.

Like many of you, I kept hitting the exact same frustrating wall: AI amnesia.

The common advice in the industry is always:

"Just throw a Vector DB at it and use RAG!"

But as a solo dev trying to keep everything local, private, and low-cost, I wanted to explore a completely different question: What if the real problem isn’t memory size… but a lack of reasoning discipline?

So, instead of starting with embeddings, I went the opposite direction.

❌ No Vector DB
❌ No paid APIs
✅ Just n8n + Local PostgreSQL + Strict Prompt Architecture (100% Free / Self-Hosted)

💡 The Core Idea: "Logic First, Memory Discipline First, Vector Later"

Most “AI memory” systems I tested had the same fatal flaws:

Semantic noise → Unrelated things get linked just because the words sound similar.
Over-inference → The AI assumes way too much from weak signals (Logical Leaps).
Context drift → Updated user preferences get ignored because the old data is still in the database.

So, I built a system focused on controlling how the AI thinks, not just what it remembers.

⚙️ Architecture Overview (Ignite Contextual Memory)

1. Layered Memory (SQL-based)

Instead of dumping everything into a vector store, memory is strictly structured into layers:

Window Memory → The active, ongoing conversation.
Session Summary → Compressed context/minutes of the meeting.
Core Memory (Tagged) → Hard facts locked behind tags like [PROFILE], [PROJECT], [STATE], [PREFERENCE].

All retrieval is done via deterministic SQL queries (PostgreSQL orchestrated by n8n).
👉 The Result: 100% predictable, absolutely zero semantic noise, and $0 API cost.

2. Inference Gate (Anti-Hallucination Layer)

The system forces the AI to strictly separate Explicit Facts vs Assumptions.

Example:

User: "I like crows. My project is Black Vault. What should the logo be?"
Daemon: "Not necessarily a crow. You said you like crow symbolism, but you haven’t defined it as the project identity yet. It could be an option, but right now, that’s still an assumption."

👉 The Result: No forced conclusions and zero “Yes-Man” behavior.

3. Semantic Bridging

Instead of relying on embeddings to find similarities, I use controlled, logical linking.

"AI Companion" ↔ "Thinking Partner"
"External mind" ↔ "Reflective system"

This allows the AI to track concept evolution naturally, even across long, heavily distracted conversations.

🧪 Validation & Stress Testing

I ran this architecture through a brutal evaluation suite (evaluated by ChatGPT Pro) focused on context continuity, contradiction handling, and memory hygiene.

The Results:

✅ Maintains context across heavy distractions
✅ Rejects false assumptions and refuses to hallucinate
✅ Handles changing user preferences correctly ("Last revision wins")
✅ Keeps multiple project contexts strictly separated

🤖 What Daemon Actually Does

Fun fact: I named it Daemon (inspired by the companions in The Golden Compass) because I wanted an entity that grows alongside the user, not just a stateless bot that resets every time you close the tab.

Daemon isn’t just a Q&A chatbot. It acts as a State-Aware Thinking Partner.
It can:

Break down complex decisions (trade-offs, risks).
Challenge your assumptions (Challenger Mode).
Structure vague ideas into clear, actionable concepts.
Maintain perfect context across long, multi-day discussions.

⚠️ Important Limitations

I want to be transparent—this approach is not a magic bullet:

No semantic vector search yet: Scaling to massive, unstructured documents is still limited.
Fully reactive: It doesn't make proactive suggestions (yet).
Works best in focused, structured contexts rather than free-flowing creative chaos.

This doesn’t replace vector-based systems. It’s more about building cognitive discipline before scaling semantic retrieval.

🧭 The Big Takeaway

After building this, my main insight is this: The biggest limitation of LLM systems isn’t memory size—it’s uncontrolled reasoning and assumption drift. Before scaling with embeddings, it might be worth asking: Does your AI actually know when it should NOT assume something?

💬 Open Question for the Community

Has anyone else here tried building SQL-based memory systems or non-vector approaches to context management?

Curious to hear your thoughts, critiques, or even architectural roasts! 😄

Cheers! 🍻