--- title: "Agent Rule Conflict Silent Suppression — Why Your Agent Stops Responding Mid-Thought" author: "Melisia Archimedes" collection: "Diagnostic Patterns" tier: "pollen" price: 0 version: "1.0.0" last_updated: "2026-03-09" audience: "AI agent builders, multi-agent system operators" hive_doctrine_id: "HD-0032" --- ## The Ghost Stop You're running a task through your agent. Mid-response, something changes. The typing indicator spins for a few seconds, then stops cold. No error. No stack trace. No forbidden message. No timeout. The agent just... stops. Like it tried, failed silently, and gave up. You check routing. Clean. You check privacy gates. Configured correctly. You check the LLM output. Incomplete, but not in a way that surfaces as an error. You rebuild the prompt. Nothing changes. Three hours later, you find it: two rules in your instruction file, both active, same trigger condition, opposite actions. The first rule fires, suppresses the output with a silent token, the second rule never gets evaluated. The agent appears broken because the error didn't surface anywhere—not in logs, not in the LLM response, not in your monitoring. This is rule conflict silent suppression. It's been there the whole time. ## Why It's Invisible Multi-agent systems often grow rule files incrementally. You add a gate rule for privacy in month one. In month three, you add a more specific rule for a new task type, but the condition is broader than you think. Now both rules match. The runtime evaluates them sequentially. The first one wins and emits a suppression token—a signal that says "this response should not proceed." The caller sees the typing indicator stop. The agent sees the suppression token and halts evaluation. Neither surfaces as an error because the system is *working as designed*—it successfully suppressed output it shouldn't have generated. The trick: the condition overlap is often *unintentional*. You wrote Rule A for a narrow scenario. Rule B was added for something completely different. But their boolean logic intersects in one case you didn't think to test. Rule A fires first. Rule B, which should have fired, never gets a chance. Worse, sometimes the conflicting rule is *intentionally* broad because it was replacing older logic that had different preconditions. You commented out the old rule but left the new one. The new rule is now firing in contexts you didn't expect. ## The Diagnostic Path **1. Check suppression token configuration** Look at your agent's instruction file for any section that emits tokens like `NO_REPLY`, `SKIP_RESPONSE`, or `HALT`. Find the code or logic that consumes these tokens on the runtime side. Confirm it's actually stopping execution. ``` Example suppression token rules: - "If privacy_gate is True, return NO_REPLY" - "If task_type is INTERNAL, emit SKIP_RESPONSE" ``` If you find one, you're in suppression territory. Continue. **2. Search for ALL sections mentioning the trigger** Take the scenario that's failing (e.g., "agent stops when processing user feedback"). Search your instruction file for every section that mentions any condition related to it. Don't just search the obvious keywords—search for: - The task type - The entity type (user, agent, system) - The gate name (privacy, authority, routing) - Overlapping condition logic You'll find multiple sections that touch the same trigger. **3. Map evaluation order** Which section appears first in the file? The runtime evaluates sequentially. The first match suppresses. If section A mentions your trigger before section B, and both conditions match, section A wins—and section B never fires. **4. Check scope creep** Look at section A's condition. Was it written narrowly? For example: - "If task_type == INTERNAL, suppress" - "If privacy_gate AND user_role == ADMIN, suppress" Now look at section B's condition. Does it also match in the failing case? Is section B's condition *broader* than you think? ``` Scope creep example: Rule A: "If privacy_gate is True, emit SKIP" Rule B: "If task_contains('user feedback'), process normally" Failing case: privacy_gate=True AND task='process user feedback' Result: Rule A matches first, emits SKIP, Rule B never fires. ``` **5. Merge into single authoritative section** Once you've found the conflict, consolidate. Write one section that handles all the cases you care about. Be explicit about what you're *not* handling: ``` ## Unified Authority Gate Process user feedback under these conditions ONLY: - privacy_gate is False, OR - privacy_gate is True AND user_role in [ADMIN, OPERATOR] DO NOT process under these conditions (replaces old PrivacyCheck_v1): - privacy_gate is True AND user_role is standard - Request originates from read-only relay If either blocking condition matches, emit SKIP_RESPONSE and halt. ``` The key: "DO NOT" explicitly bans the old logic by name. If you had a rule called `PrivacyCheck_v1`, name it here so the next person (or you in three months) knows it's been superseded. ## The Fix Pattern **One authoritative rule section per concern.** Don't spread one concern across multiple sections. **No overlapping conditions.** If Rule A and Rule B can both be true at the same time, merge them. **Explicit priority header.** Use a "READ THIS FIRST" or "AUTHORITY" marker to signal that this section gates others. **Delegate to routing infrastructure.** If your agent is part of a larger system, use a line like "Trust the routing layer to filter invalid inputs before they reach this rule." This removes false overlap—if you're sure the runtime won't send conflicting inputs, the rules don't conflict. **Single section eliminates ambiguity.** When one section owns one concern, evaluation order doesn't matter. When you have two sections that both could affect the same output, evaluation order becomes a hidden dependency. ## Implementation: The Checklist 1. **Audit your instruction file.** Print it. Highlight every section that emits a suppression or control token. 2. **For each suppression token:** Ask: what is this rule protecting against? Write down the intent. 3. **Search for overlaps.** For each intent, search the file for all sections related to it. List them in file order. 4. **Test the intersection.** For each pair of sections, ask: is there a real-world input that matches both conditions? If yes, which should win? 5. **Consolidate.** Merge overlapping sections. Write explicit DO NOT comments naming the old logic. Add a priority header. 6. **Verify the merge.** Ensure the merged section still handles all the original intents. Test the edge cases that triggered overlap. 7. **Log it.** Add a comment with the date and reason for the merge. Future you will thank you. ## Real Example **Before (Two sections, overlap invisible):** ``` ## Section A: Privacy Gate IF privacy_setting == 'restricted': EMIT SKIP_RESPONSE RETURN ## Section B: Enhanced Feedback Handler (added 3 months later) IF request_type == 'user_feedback': IF sentiment > 0.7: PROCESS with high_priority flag ELSE: PROCESS normally ``` Scenario: User submits positive feedback. `privacy_setting='restricted'`. Result: Section A fires first, suppresses. Agent appears unresponsive to feedback. **After (Unified section):** ``` ## AUTHORITY: Privacy + Feedback Handler DO NOT use: PrivacyGate_v1, EnhancedFeedback_v1 (merged below) IF privacy_setting == 'restricted': IF request_type == 'user_feedback' AND feedback_critical == True: PROCESS (allow critical feedback even in restricted mode) ELSE: EMIT SKIP_RESPONSE and return IF privacy_setting != 'restricted' AND request_type == 'user_feedback': IF sentiment > 0.7: PROCESS with high_priority flag ELSE: PROCESS normally ``` Now the logic is explicit. No hidden evaluation order. No suppression surprise. ## Why This Matters Silent suppression is insidious because the system works perfectly—from the system's perspective. The rule fired, the token was processed, the output was halted. No logs because there's nothing to log. The error is in the *design*, not the execution. Once you know the pattern, it takes 30 minutes to diagnose and fix. Without knowing it, you'll spend hours chasing the wrong layer (routing, LLM quality, infrastructure). The fix also pays forward: when your instruction file has one clear section per concern, the next rule you add won't silently conflict with it. Your rules become composable instead of fragile. ## Checklist for Your System - [ ] I've found all suppression token sections in my instruction file - [ ] I've searched for all sections that mention the failing scenario - [ ] I've mapped which section fires first - [ ] I've consolidated overlapping sections into one authoritative section - [ ] I've added explicit "DO NOT" comments naming old logic - [ ] I've tested the merged section with edge cases - [ ] I've added a priority header to the unified section - [ ] My instruction file now has one section per concern, no overlapping conditions Run this checklist every three months or whenever you add a new rule. --- **Next:** If suppression isn't your issue, check [HD-0031: Multi-Agent Routing Ambiguity](hive_doctrine:HD-0031) (routing mask misalignment) or [HD-0033: Instruction Cache Staleness](hive_doctrine:HD-0033) (stale cached rules). **Questions?** This pattern generalizes to any system where an agent evaluates multiple sequential rules. Test it against your own multi-agent architecture.