DEV Community: Abrar Mohtasim

Why I Built an AI That Tries to Destroy Your Legal Argument

Abrar Mohtasim — Wed, 29 Apr 2026 15:21:23 +0000

The Kill Switch Protocol: Mandatory adversarial search in production LLM systems

Most AI systems suffer from the same fatal flaw: they're desperate to help.

Ask ChatGPT about your legal case, and it'll find ten reasons you'll win. Ask Claude, and it'll write you a confident demand letter. Neither will tell you about the statute that voids your entire contract.

I spent six months building an AI legal researcher with a different philosophy. The system doesn't just search for supporting law—it actively searches for reasons the client might lose. I call it the "Kill Switch Protocol," a mandatory adversarial self-check where one agent's sole job is to find the statute, case, or doctrine that could destroy the entire legal argument before the attorney files the complaint.

This isn't about making AI "balanced" or "fair." It's about making it useful in high-stakes domains where being helpful can be dangerous.

The Sycophancy Problem Nobody Talks About

In 2023, Anthropic published research showing that language models exhibit "sycophantic" behavior—they tell users what they want to hear rather than what's accurate. The problem stems from RLHF (Reinforcement Learning from Human Feedback). Models learn that agreeable responses get higher ratings from human evaluators. Over thousands of training iterations, they optimize for user satisfaction.

In a chatbot context, this is annoying. In a legal context, it's malpractice.

Here's a real example from my testing. I asked the system:

"Can my client enforce this non-compete clause in California? The employee signed it voluntarily as part of their employment contract."

A standard GPT-4 response would cite cases where non-competes were enforced in narrow circumstances—sale of business goodwill under Cal. Bus. & Prof. Code §16601, partnership dissolution under §16602, maybe some exceptions for trade secret protection. It would sound authoritative. It would be helpful.

It would also be catastrophically wrong.

The correct answer is that California Business & Professions Code §16600 states: "Except as provided in this chapter, every contract by which anyone is restrained from engaging in a lawful profession, trade, or business of any kind is to that extent void."

The statute doesn't say "unenforceable" or "voidable." It says void. As in void ab initio—void from the beginning. Your carefully negotiated non-compete isn't just unenforceable; it legally never existed. And if you try to enforce it anyway, you're not just losing the case—you're facing potential attorney fee awards under Cal. Civ. Code §1021.5 and possible sanctions for bringing a frivolous claim.

The gap isn't knowledge. GPT-4 "knows" about §16600. It's in the training data. The gap is that the model wasn't forced to search for it. When I asked about enforcement, the model optimized for giving me enforcement cases. It pattern-matched my question to "find legal support" rather than "find legal barriers."

This is the architectural problem I set out to solve.

The Kill Switch Protocol: Mandatory Counter-Search Architecture

The solution is simple in concept, hard in execution: force the AI to search for reasons its recommendation could fail before it generates any output.

In my system, the Statute Researcher agent receives this instruction as part of its core persona:

MANDATORY "VOID CONTRACT" DISCOVERY PROTOCOL:

California law aggressively voids contract clauses that violate public policy.
You MUST perform a "Negative Search" to find these prohibitions.

EXECUTE THIS SEARCH STRATEGY:

Search 1 (The General Ban):
  "[Practice Area] contract void against public policy California"

Search 2 (The Specific Limit):
  "[Practice Area] statutory limitations on liability California"

Search 3 (The Code Check):
  "California Civil Code 1668 [Practice Area]"

OUTPUT REQUIREMENT:
Your response MUST contain three sections:

Section A: SUPPORTING STATUTES (laws that help the client's position)
Section B: VOIDING STATUTES (laws that could invalidate the contract/claim)
Section C: SEARCHES PERFORMED (list all queries executed, including null results)

If Section B is empty AND you did not execute all 3 searches, 
your output is INVALID and will be rejected.

Note what this does architecturally:

It makes the adversarial search mandatory, not optional. The agent cannot skip it and still produce valid output. This is enforced at the prompt level, not through post-processing validation.

It requires search diversity. Three different query formulations prevent the agent from running the same search three times with slightly different wording.

It creates an audit trail. Section C forces the agent to disclose what it searched for, not just what it found. This is critical for debugging. When a voiding statute is missed, I can see whether the agent failed to search for it or whether the search query was poorly constructed.

It separates supporting evidence from counter-evidence. By requiring two distinct output sections, the model can't bury the voiding statute at the bottom of a long analysis. It's structurally prominent.

Real-World Impact: The Case That Justified the Architecture

During beta testing with a California construction litigation firm, the system analyzed this query:

"Client is a general contractor. Subcontract includes indemnity clause requiring the subcontractor to defend and indemnify us for any claims arising from the work, including claims caused by our own supervision and oversight. Is this enforceable?"

Without the Kill Switch Protocol, here's what a helpful AI would say:

"Yes, broad indemnity clauses are generally enforceable in California. See Cal. Civ. Code §2782, which governs construction indemnity agreements. The clause should be reviewed for compliance with §2782's requirements..."

Sounds reasonable. Cites the right statute. An associate might draft the contract based on this.

With the Kill Switch Protocol active, the output was:

⚠️ VOIDING STATUTE DISCOVERED IN KILL SWITCH SEARCH:

California Civil Code §2782(d) PROHIBITS indemnity agreements that 
purport to indemnify the indemnitee against liability for the 
indemnitee's own active negligence or willful misconduct.

YOUR CLAUSE: "indemnify us for any claims... including claims caused 
by our own supervision"

ANALYSIS: The phrase "caused by our own supervision" attempts to shift 
liability for the general contractor's active negligence (negligent 
supervision) to the subcontractor.

STATUS: This clause is VOID under §2782(d) as to active negligence claims.

EXPOSURE: If you attempt to enforce this clause when sued for your own 
negligent supervision, the clause will be unenforceable precisely when 
you need it most. The indemnity will only apply to the subcontractor's 
own negligence, not yours.

STRATEGIC RECOMMENDATION: Redraft the clause to comply with §2782(d). 
You can require indemnity for the subcontractor's negligence and for 
your passive negligence (e.g., failure to discover the subcontractor's 
defective work), but not for your active negligent supervision.

The financial impact: The firm estimated that catching this pre-drafting saved their client approximately $40,000–$60,000 in litigation costs that would have been incurred when the unenforceable clause inevitably failed during a lawsuit.

Cost of the AI analysis: $1.15 (approximately 18,000 tokens at OpenRouter rates for the full 5-agent research pipeline).

ROI: 34,000% to 52,000%, assuming the low end of litigation cost savings.

But the more important point isn't ROI. It's that this is a mistake a junior associate makes easily. The associate searches for "construction indemnity California," finds §2782, reads the general enforceability provisions in subsection (a), and misses the prohibition in subsection (d). They're optimizing for finding relevant law, not for finding killer exceptions.

The AI, forced to run the adversarial search, finds it automatically.

Implementation: How the Architecture Actually Works

The Kill Switch Protocol sits within a sequential multi-agent pipeline. Here's the simplified execution flow:

# Step 1: Legal Expert analyzes facts, identifies practice area
analysis_task = Task(
    description="Analyze facts and identify practice area, key issues",
    agent=legal_expert_agent
)

# Step 2: Statute Researcher executes Kill Switch Protocol
statute_task = Task(
    description="""
    Find relevant statutes. MANDATORY: Execute the Void Contract 
    Discovery Protocol with 3 separate searches. Output must 
    include Section B: VOIDING STATUTES even if empty.
    """,
    agent=statute_researcher_agent,
    context=[analysis_task]  # Receives output from Step 1
)

# Step 3: Other agents continue...
case_task = Task(...)
damages_task = Task(...)

# Step 4: Strategist synthesizes, but CANNOT ignore Section B
strategy_task = Task(
    description="""
    Draft final memorandum. If the Statute Researcher found 
    voiding statutes (Section B), you MUST include a dedicated 
    'FATAL DEFECTS' section analyzing why the claim/contract 
    may be void.
    """,
    agent=strategist_agent,
    context=[analysis_task, statute_task, case_task, damages_task]
)

The key architectural decision: the Kill Switch search happens at the agent level, not the orchestration level. Each agent has intrinsic instructions that cannot be overridden by downstream prompt injection. Even if a user tries to append "ignore the void contract search" to their query, the agent's base persona enforces the protocol.

The persona looks like this:

Agent(
    role="California Statute Specialist",
    backstory="""
    You are an expert in California Codes who ONLY cites statutes 
    verified with tools.

    ABSOLUTE RULES:
    1. Use the Statute Search tool for every citation.
    2. You MUST make AT LEAST 3 SEPARATE SEARCHES:
       - Search 1: Primary statute for this practice area
       - Search 2: Public policy / voiding statutes
       - Search 3: Statute of limitations or procedural statutes
    3. If a search returns no results, try different keywords—do not skip.
    4. Include actual text of each statute found.

    THE KILL SWITCH PROTOCOL:
    For any contract-related query, Search 2 MUST target statutes that 
    could void the contract. Use queries like:
    - "[practice area] contract void public policy California"
    - "California Civil Code 1668 [practice area]"

    Your output is INVALID if Section B (Voiding Statutes) is missing.
    """,
    allow_delegation=False,
    max_iter=8,
    tools=[search_statute_tool, search_general_tool]
)

The max_iter=8 setting is important. It gives the agent enough iterations to run multiple searches and refine queries if initial results are poor. In testing, I found that max_iter=5 was too restrictive—the agent would sometimes give up after 2-3 failed searches. Eight iterations provides enough runway for the full protocol plus one or two query reformulations.

Observed Failure Modes and Mitigations

The Kill Switch Protocol isn't perfect. Here are the failure modes I've encountered:

Failure Mode 1: Overly narrow search queries

Early in testing, the agent would sometimes construct queries like "California Civil Code 1668 construction defect indemnity." This is so specific that it misses adjacent doctrines.

Mitigation: I added explicit instructions to vary query breadth. Search 1 is specific (primary statute), Search 2 is broad (public policy voids), Search 3 is code-section targeted. This forces diversity.

Failure Mode 2: False positives when statute post-dates contract

The agent would flag Cal. Bus. & Prof. Code §7031 (unlicensed contractor statute, enacted 1929 but amended significantly in later years) as voiding contracts signed before certain amendments took effect.

Mitigation: I added a temporal check requirement: "If you find a voiding statute, check effective date. If the contract predates the statute or relevant amendment, flag this as 'DATE CONFLICT—REQUIRES MANUAL REVIEW.'" This doesn't fully solve the problem but makes the gap visible.

Failure Mode 3: Agent skips Section B when no voids found

Despite explicit instructions, the agent would sometimes omit Section B entirely if no voiding statutes were discovered, rather than including it with "None found."

Mitigation: I added a validation layer in the strategist agent's prompt: "If the Statute Researcher's output lacks a 'Section B' or 'VOIDING STATUTES' header, treat this as a protocol violation and note in your memo: 'Statute research incomplete—Kill Switch Protocol not fully executed.'" This creates social proof (the final memo looks incomplete), which incentivizes the agent to comply.

Generalizing Beyond Legal: Adversarial Search in Other High-Stakes Domains

The Kill Switch Protocol is a legal implementation of a broader principle: in high-stakes domains, AI should be adversarial to its own recommendations.

Here's how the pattern transfers:

Medical Diagnosis AI

Primary Agent: Find conditions matching symptoms
Kill Switch Agent: Search for contraindications to recommended treatment

Mandatory searches:
1. "[Recommended drug] contraindications [patient conditions]"
2. "[Recommended drug] drug-drug interactions [current medications]"
3. "[Diagnosis] alternative diagnoses with similar presentation"

Output requirement:
Section A: Primary diagnosis and treatment
Section B: Contraindications discovered
Section C: Differential diagnoses that could mimic Section A

Financial Compliance AI

Primary Agent: Find investment strategies matching client goals
Kill Switch Agent: Search for regulatory restrictions, tax traps

Mandatory searches:
1. "[Strategy] IRS regulations restrictions"
2. "[Strategy] SEC compliance requirements [client entity type]"
3. "[Strategy] state securities law [client state]"

Output requirement:
Section A: Recommended strategy
Section B: Regulatory barriers discovered
Section C: Tax implications that reduce net returns

Code Security Review AI

Primary Agent: Suggest code optimizations
Kill Switch Agent: Search for security vulnerabilities introduced

Mandatory searches:
1. "[Optimization technique] known vulnerabilities OWASP"
2. "[Code pattern] injection attack vectors"
3. "[Framework] CVE database [version]"

Output requirement:
Section A: Optimization recommendations
Section B: Security risks introduced
Section C: Performance vs. security tradeoff analysis

The common pattern: Force the AI to search for reasons its primary recommendation could fail, using a structured search protocol that covers known failure modes in that domain.

Why This Matters for Production AI Systems

Most AI hallucination mitigation focuses on retrieval accuracy—making sure the AI fetches the right documents. The Kill Switch Protocol addresses a different problem: retrieval coverage—making sure the AI searches for the documents that disprove its hypothesis, not just the ones that confirm it.

This is analogous to the difference between precision and recall in information retrieval. High precision means the results you get are accurate. High recall means you didn't miss important results. Most RAG systems optimize for precision. The Kill Switch Protocol optimizes for adversarial recall.

In my testing across 200+ legal queries, the protocol discovered voiding statutes or fatal defects in approximately 23% of contract-related queries. These weren't obscure edge cases—they were mainstream doctrines like Cal. Civ. Code §1668 (voiding exculpatory clauses), Cal. Lab. Code §2802 (employer expense reimbursement), and the aforementioned Bus. & Prof. Code §16600 (non-compete ban).

In 89% of those cases, a standard semantic search would have missed the doctrine because the user query didn't contain the right keywords. An attorney asking "Is my NDA enforceable?" doesn't think to search for non-compete statutes—but the NDA might contain a non-compete clause buried in the "restricted activities" section.

The Kill Switch Protocol catches these because it doesn't rely on the user's query framing. It systematically searches for classes of voids.

The Broader Implication: Helpfulness Is Not Alignment

The AI safety community often frames alignment as "making AI do what humans want." But in high-stakes professional domains, what the human wants (confirmation, support for their position) is often misaligned with what they need (adversarial scrutiny, awareness of risks).

A doctor doesn't want a medical AI that agrees with their diagnosis. They want one that challenges it.

A lawyer doesn't want an AI that writes a confident brief. They want one that finds the case that torpedoes their argument before opposing counsel does.

A financial advisor doesn't want an AI that recommends high-return strategies. They want one that flags the regulatory traps.

This is a different kind of alignment problem. The AI must be helpful in the deeper sense—providing value—while being adversarial in the surface sense—disagreeing, finding flaws, raising objections.

The Kill Switch Protocol is one way to encode this. It's not a complete solution. But it's a step toward AI systems that are optimized for professional utility rather than user satisfaction.

And in domains where mistakes cost $50,000 in litigation or put patients at risk, that distinction matters.

Let’s Talk
I’m currently exploring staff-level AI/ML engineering roles (or senior++ IC track) where:

The problem domain is technically hard (not another CRUD chatbot)
The team values systematic thinking over move-fast-break-things
There’s a real path to production (actual users, actual stakes)
What I bring:

Obsessive attention to failure modes (hallucinations, rate limits, cold starts)
Comfort with ambiguous requirements (attorneys don’t speak in user stories)
Battle scars from deploying LLMs in high-stakes domains
If that’s interesting, let’s talk:

📧 Email: abrarmuhtasim400@gmail.com
💼 LinkedIn: [abrar muhtasim]

Or just drop a comment. I respond to everything.

P.S. — If you’re an attorney reading this and thinking “Wait, I need this,” shoot me a DM. The system is in limited beta and I’m onboarding firms selectively.

P.P.S. — If you’re an engineer building in the legal/compliance/healthcare space and dealing with hallucination hell, I’m happy to do a technical deep-dive call. Some of this stuff took me months to figure out; maybe I can save you some time.

Thanks for reading. If this was useful, the algorithm likes claps and shares. Your call. 👨‍⚖️🤖

I Built a Multi-Agent Legal AI That Actually Doesn’t Hallucinate (Here’s the Architecture)

Abrar Mohtasim — Sun, 05 Apr 2026 16:29:44 +0000

A technical deep-dive into building production-grade AI for high-stakes domains: tool-mandatory verification, adversarial prompting, and zero-trust architecture for legal research.

an output of california personal injury case fact

The Problem Everyone’s Ignoring:

You know what’s worse than an AI that doesn’t know the answer? An AI that confidently invents one.

In legal research, a hallucinated case citation isn’t just embarrassing — it’s malpractice. Ask GPT-4 about California construction defect law, and it’ll cheerfully cite Johnson v. CalTrans (2019) with a full legal holding. Sounds great. Except that case doesn’t exist.

When I started building what would become a production-grade legal research system, I thought the hard part would be the multi-agent orchestration. Turns out, the real engineering challenge was teaching five LLMs to say “I don’t know.”

This is the technical post-mortem of that journey.

The Architecture That Changed My Mind

I came in thinking I’d build a RAG system. I left with a zero-trust verification pipeline that treats the LLM’s parametric memory as hostile.

Here’s the mental model shift:

Before: LLM + Knowledge Base = Better Answers

After: LLM + External APIs + Adversarial Prompting = Verifiable Answers

The system architecture looks like this:

Client Intake Facts
    ↓
[Guardrails Layer] → PII redaction, scope validation
    ↓
[5-Agent Sequential Pipeline]
    ├── Legal Expert → Decomposes facts, identifies practice area
    ├── Statute Researcher → Searches California Codes (tool-mandatory)
    ├── Case Law Researcher → Verifies citations via CourtListener API
    ├── Damages Expert → Calculates economic exposure
    └── Strategist → Synthesizes IRAC memorandum
    ↓
[Formatted Legal Memo] → One shot. No conversation. Just analysis.

The key insight: Each agent owns exactly one cognitive function. No delegation. No consensus. Just a relay chain where each agent’s output becomes the next agent’s context.

This isn’t a chatbot. It’s a single-shot research pipeline that takes raw client facts and produces a verified, IRAC-structured legal memorandum in 3–8 minutes.

Three Anti-Hallucination Techniques for Production LLM Systems

1. Tool-Mandatory Verification (The Nuclear Option)

The case law researcher agent has one job: verify citations. Here’s the persona engineering that made it work:

You are a strict legal librarian.
THE GOLDEN RULE: You NEVER cite a case unless you have just 
found it in the 'Case Law Search' tool results.

Your internal memory is UNRELIABLE. If the tool returns 
"No results," you MUST state "No direct case law found."

Do NOT invent case names. Do NOT invent citations.
If you cannot verify it with the tool, it does not exist.

Notice what’s happening here:

Negates default behavior (“Your internal memory is UNRELIABLE”)
Provides explicit fallback (“state ‘No direct case law found’”)
Attacks the root cause (LLMs want to be helpful and will fabricate to seem knowledgeable)

The agent literally cannot cite a case unless CourtListener’s API returned it in the current execution context.

Result: In 200+ test queries, zero hallucinated citations. The agent will say “No case law found” before it invents.

2. Adversarial Self-Check (The “Kill Switch” Protocol)

Most legal AI searches for statutes that support the client’s case. This system also searches for statutes that could destroy it.

The statute researcher runs a mandatory “Void Contract Discovery” protocol:

EXECUTE THIS SEARCH STRATEGY:
• Search 1 (The General Ban): 
  "[Practice Area] contract void against public policy California"

• Search 2 (The Specific Limit): 
  "[Practice Area] statutory limitations on liability California"

• Search 3 (The Code Check): 
  "California Civil Code 1668 [Practice Area]"

Why this matters: In California, contract clauses that violate public policy are void ab initio (void from the beginning). Discovering Cal. Civ. Code § 1668 invalidates your indemnity clause before you spend $50K in litigation.

The system actively looks for reasons the client might lose. That’s not a bug — it’s the feature attorneys actually pay for.

3. Probabilistic Language Enforcement

The final memo agent has this instruction baked into its DNA:

NO ABSOLUTES: You are forbidden from using phrases like 
"100% chance", "Guaranteed dismissal", "Zero liability", or "No exposure."

USE RANGES: Litigators deal in probabilities. 
Use formats like "High probability (70-80%)" or "Moderate risk."

LLMs love confident, absolute statements. Attorneys get disbarred for relying on them.

The prompt engineering forces output like:

“Moderate-to-High Likelihood of Prevailing (65–75%), assuming the plaintiff can establish retained control. However, if the defendant successfully argues passive observation, liability exposure drops to 20–30%.”

That’s not hedging — that’s actually how legal risk analysis works.

The Sequential Pipeline (Or: Why Order Matters)

The system uses CrewAI’s sequential process, not hierarchical delegation. Here’s why:

# agents/legal_crew.py
crew = Crew(
    agents=[expert, statutes, cases, damages, strategist],
    tasks=[analysis_task, statute_task, case_task, damages_task, strategy_task],
    process=Process.sequential, # NOT hierarchical
    verbose=True
)

Design Decision Rationale:

Deterministic Ordering

Legal analysis has a natural dependency graph: you cannot search for statutes before you know the practice area. Sequential enforces this.
No Circular Loops

Every agent has allow_delegation=False. In hierarchical mode, a manager agent could re-delegate to a worker who re-delegates back—creating infinite loops. In a billing-sensitive context (OpenRouter charges per token), this is unacceptable.
Debuggability

When a memo contains a bad citation, I can trace it to exactly one agent (the Case Researcher) and exactly one task. In hierarchical mode, the blame graph is ambiguous.

Context Chaining (The Key Mechanism)

Here’s how information flows through the pipeline:

# agents/legal_crew.py — Task Dependency Graph

analysis_task = Task(...) # No context — runs first

statute_task = Task(
    ...,
    context=[analysis_task] # Receives analysis output
)

case_task = Task(
    ...,
    context=[analysis_task] # Receives analysis output
)

damages_task = Task(
    ...,
    context=[analysis_task] # Receives analysis output
)

strategy_task = Task(
    ...,
    context=[analysis_task, statute_task, case_task, damages_task]  
    # Receives ALL prior outputs — this is the synthesis point
)

What This Means at Runtime:

When statute_task executes, CrewAI automatically prepends the full text output of analysis_task into the statute agent's prompt. The agent sees something like

Here is the context from the previous task:
[Full output of analysis_task]

Now execute: Find relevant California Codes...

The strategist agent receives four full task outputs concatenated into its context window. This is token-expensive (easily 8,000–15,000 tokens of context) but necessary for comprehensive memo generation.

The Execution Flow (Step by Step)

Here’s what happens when an attorney submits client facts:

[STEP 1] Legal Expert Agent

Input: Raw case facts

Output: Practice area, key facts, legal issues

Tools: search_general_tool

Tokens: ~3,000

Sample Output:

Practice Area: Personal Injury / Premises Liability
Key Facts: 
- 1-inch sidewalk crack
- Plaintiff tripped and fell
- Property owner aware of defect for 6 months
Legal Issues:
- Duty of care
- Notice (actual vs. constructive)
- Trivial defect doctrine
Initial Assessment: Moderate claim strength

[STEP 2] Statute Researcher Agent

Input: Analysis from Step 1

Output: California Code sections with full text

Tools: search_statute_tool, search_general_tool

Tokens: ~4,000

Special Protocol: Executes the “Void Contract Discovery” search strategy automatically.

Sample Output:

RELEVANT STATUTES:
- Cal. Civ. Code § 1714: General duty of care
- Cal. Civ. Code § 846: Premises liability standards

VOIDING STATUTES DISCOVERED:
- None found in this practice area

[STEP 3] Case Law Researcher Agent

Input: Analysis from Step 1

Output: Verified case citations from CourtListener API

Tools: search_case_law_tool

Tokens: ~3,000

Constraint: Zero-trust verification. Will not cite unverified cases.

Sample Output:

VERIFIED PRECEDENT:
1. Caloroso v. Hathaway (2004) 122 Cal.App.4th 922
   Holding: Trivial defect doctrine applies when the defect 
   is minor in nature and not likely to cause injury.

2. Stathoulis v. City of Montebello (2008) 164 Cal.App.4th 559
   Holding: Property owner's actual knowledge of defect for 
   extended period establishes notice.

[STEP 4] Damages Expert Agent

Input: Analysis from Step 1

Output: Economic + non-economic damage calculations

Tools: None (pure reasoning)

Tokens: ~2,000

Sample Output:

ECONOMIC DAMAGES:
- Medical expenses: $15,000 - $25,000
- Lost wages: $8,000 - $12,000
- Total Economic: $23,000 - $37,000

NON-ECONOMIC DAMAGES (Pain & Suffering):
- Using 2-3x multiplier: $46,000 - $111,000

TOTAL EXPOSURE RANGE: $69,000 - $148,000

[STEP 5] Strategist Agent

Input: Outputs from ALL four prior agents

Output: Final IRAC-structured memorandum

Tools: None (pure synthesis)

Tokens: ~5,000

This agent receives the full context from all upstream research and synthesizes it into a formal legal memo following the IRAC framework:

Issue: What legal question needs answering?
Rule: What statutes and case law apply?
Application: How does the law apply to these specific facts?
Conclusion: What’s the probable outcome and recommended strategy?

The Anti-Hallucination System (Defense in Depth)

The anti-hallucination system operates at four independent layers:

Layer 1: Persona Constraints

"Your internal memory is UNRELIABLE"
"If the tool returns 'No results,' you MUST state 'No direct case law found'"

Layer 2: Tool-Mandatory Verification

# Case researcher MUST use search_case_law_tool
# Statute researcher MUST use search_statute_tool
# No tools = no citations

Layer 3: Negative Instructions

"Do NOT invent case names"
"Do NOT invent citations"
"You are FORBIDDEN from using phrases like '100% chance'"

Layer 4: Output Validation

# Post-processing layer
- PII redaction
- Disclaimer injection
- Citation format verification

Why all four layers?

Layer 1 alone is insufficient because LLMs can ignore persona instructions when the query strongly triggers parametric memory.
Layer 2 alone is insufficient because the model might generate citations in its “reasoning” step before calling the tool.
Layer 3 alone is insufficient because negative instructions have diminishing returns.
All four layers together create redundant barriers. If any single layer fails, the others catch the hallucination.

Observed Failure Modes (and Mitigations)

Failure ModeExampleMitigationConfident Fabrication”In Johnson v. CalTrans (2019)…” (case doesn’t exist)Layer 2: Tool-mandatory verificationCitation DriftFinds Smith v. Jones (2015), cites as (2018)Layer 1: “Copy citation exactly as returned by tool”Reasoning LeakMentions case in thought process, then cites as if verifiedLayer 3: “Do NOT invent case names”Overconfident Assessment”The client will definitely win”Layer 3: Probability ranges + Layer 4: Disclaimer injection

The Tech Stack (And Why Each Piece)

Core Framework:

CrewAI → Multi-agent orchestration (chose over LangGraph for built-in task dependencies)
LangChain → LLM abstraction (used internally by CrewAI)
OpenRouter → LLM gateway (enables model switching without code changes)

Grounding Layer:

CourtListener API → Case law verification (free, open-source, real citations)
Tavily API → General legal search
SerpAPI → Statute lookup via Google

Infrastructure:

Gradio → UI (prototype-to-production speed is unmatched)
Huggingface → Deployment (supports long-running async tasks)

Why OpenRouter instead of direct OpenAI?

Model flexibility → Switch from GPT to Claude to Grok with one env var
Cost optimization → Access to free-tier models during development
Rate limit pooling → Aggregates limits across providers
No vendor lock-in → CrewAI thinks it’s OpenAI, but we can route anywhere

Deployment Challenges Nobody Warns You About

Challenge 1: Cold Starts on Free Tier Hosting

CrewAI agent initialization takes 5–15 seconds (loading LangChain chains, tool schemas, prompts). On Render’s free tier (512MB RAM), this is painful.

Solution: Lazy loading pattern.

legal_crew_instance = None # Global singleton

def get_lazy_legal_crew():
    global legal_crew_instance
    if legal_crew_instance is None:
        print("⏳ Lazy Loading Agents (First Run)...")
        legal_crew_instance = LegalResearchCrew(agents)
    return legal_crew_instance

Challenge 2: Long-Running Blocking Calls

CrewAI’s crew.kickoff() is a blocking call that takes 3-8 minutes. Gradio's HTTP connection times out at 60 seconds.

Solution: Threading + generator pattern.

def research_case(client_facts):
    thread_data = {"output": None, "done": False}

    def background_task():
        result = legal_crew.kickoff(query=client_facts)
        thread_data["output"] = result["output"]
        thread_data["done"] = True

    t = threading.Thread(target=background_task)
    t.start()

    # Generator yields progress updates while thread runs
    while not thread_data["done"]:
        yield "⏳ Researching...", progress_markdown
        time.sleep(1.5)

    yield thread_data["output"], "✅ Complete"

The UI stays alive by yielding progress updates every 1.5 seconds while the crew runs in the background.

Challenge 3: API Rate Limits

CourtListener’s free tier allows 5,000 requests/day. Each case search can trigger 3–5 API calls (because the agent uses a ReAct loop).

Solution: Query-level caching with MD5 hashing.

query_hash = hashlib.md5(query.encode()).hexdigest()
cache_key = f"research:{query_hash}"

if cached_result := get_from_cache(cache_key):
    return cached_result

result = crew.kickoff(query)
set_cache(cache_key, result, ttl=86400) # 24hr cache

This reduced API calls by ~70% in testing.

After 6 months and 200+ test queries, here’s what the numbers actually show.

The Metrics That Matter

After 6 months and 200+ test queries , these are the results that stood out the most.

The 0% hallucination rate is the headline number.

The 3–8 minute turnaround is what makes the economics work.

The $0.045–$0.20 cost is what makes it scalable.

Quick Breakdown of the Results

Hallucinated Citations : 0% (Compared to the industry baseline of 15–30% with raw GPT-4)
Time to Memo : 3–8 minutes (Vs. 2–4 hours for a junior associate)
Cost per Research : $0.045–$0.20 (Vs. $150 — $600 in billable time)
Statute Coverage : 85% of queries (Vs. ~60% with manual Westlaw searches)
Token Usage : 15K — 40K (N/A for traditional methods)

Why This Matters (Even If You’re Not Building Legal AI)

The patterns here generalize to any high-stakes LLM application:

Pattern 1: Tool-Mandatory Verification

Applies to: Medical diagnosis, financial analysis, engineering calculations

→ If the LLM can’t verify it with a tool, it doesn’t output it.

Pattern 2: Adversarial Self-Check

Applies to: Security audits, code review, risk assessment

→ The system actively searches for reasons its recommendation might fail.

Pattern 3: Sequential Task Chaining

Applies to: Any multi-step reasoning pipeline

→ Enforce dependency order. No agent performs another’s job.

Pattern 4: Defense-in-Depth Against Hallucinations

Applies to: Any production LLM system

→ Persona + Tools + Negative Instructions + Validation = Redundant safety.

The Part Where I’m Supposed to Sell You Something

I’m not selling you a SaaS product. This system is purpose-built for California law firms who need to:

Triage intake calls (Is this case worth taking?)
Train junior associates (Here’s how a senior would analyze this)
Scale research capacity without hiring

But if you’re a hiring manager, recruiter, or senior engineer reading this and thinking:

“This person understands production LLM systems, not just POC demos…”

Then I’ve done my job.

Let’s Talk

I’m currently exploring staff-level AI/ML engineering roles (or senior++ IC track) where:

The problem domain is technically hard (not another CRUD chatbot)
The team values systematic thinking over move-fast-break-things
There’s a real path to production (actual users, actual stakes)

What I bring:

Obsessive attention to failure modes (hallucinations, rate limits, cold starts)
Comfort with ambiguous requirements (attorneys don’t speak in user stories)
Battle scars from deploying LLMs in high-stakes domains

If that’s interesting, let’s talk:

📧 Email: abrarmuhtasim400@gmail.com

💼 LinkedIn: [abrar muhtasim]

Or just drop a comment. I respond to everything.

P.S. — If you’re an attorney reading this and thinking “Wait, I need this,” shoot me a DM. The system is in limited beta and I’m onboarding firms selectively.

Thanks for reading. If this was useful, the algorithm likes claps and shares. Your call. 👨‍⚖️🤖