Skip to content
BSWEN
Blog

System Prompt Rules for Reliable Agent Verification: What to Tell Your LLM

Cowrie
Cowrie
Dev @ Bswen

My AI agent kept telling me it successfully published articles to external platforms. But when I checked, nothing was there.

The HTTP response was 200 OK. The agent said “completed with checkmark emoji.” Yet the article was stuck in “pending review” status, waiting for moderation.

This wasn’t a bug in my code. It was a bug in my system prompt.

The Problem

I was building a multi-agent content publishing system. One agent handled platform publishing. It would call an API, receive a response, and report success back to the orchestrator.

publisher_agent.py
def publish_article(self, article, platform):
    response = platform_api.publish(article)
    # Agent assumed 200 OK = published
    return {
        "status": "published",
        "article_id": response["id"]
    }

The agent’s system prompt was generic:

original_prompt.md
You are a publishing assistant. Use the available tools to publish content.
Always be accurate and report the final status of each operation.

Seems reasonable, right? Here’s what happened:

  1. Agent calls publish API
  2. API returns {"success": true, "status": "pending_review", "task_id": "abc123"}
  3. Agent reports to orchestrator: “Article published successfully”
  4. Orchestrator marks task as complete
  5. Next agent in pipeline starts assuming article is live
  6. Reality: Article is still in moderation queue

The downstream agent tried to fetch the live article URL. It failed because the article wasn’t published yet.

Why This Happens

LLM agents don’t magically understand verification. They interpret tool return values based on:

  1. Their training on typical REST APIs - HTTP 200 usually means success
  2. The system prompt’s explicit instructions - or lack thereof
  3. The example behaviors shown - what they’ve seen before

My prompt said “be accurate” but didn’t define what accuracy means. The agent assumed 200 OK + no error message = published. That’s a reasonable assumption for many APIs, but not for async publishing workflows.

This is not a failure of the LLM. It’s expected behavior. The agent did exactly what the prompt implied.

The Solution: Explicit Verification Rules

I rewrote the system prompt with explicit verification rules:

verification_prompt.md
You are a publishing assistant. Use the available tools to publish content.


## Verification Requirements


1. **API Response Verification**
   - Never trust HTTP status codes alone
   - Parse response body for explicit success indicators
   - Look for fields like: success, published, status, error
   - If status is "pending", "processing", or "reviewing":
     - Report "submitted" not "completed"
     - Provide task ID or tracking reference


2. **File Operation Verification**
   - After writing files, read back and verify content
   - Check file exists AND contains expected data
   - Do not assume write success from lack of errors


3. **Async Operation Handling**
   - For long-running operations, implement polling
   - Set reasonable timeouts (30-60 seconds typical)
   - Report "in progress" with task ID, not "completed"


4. **Precise Status Language**
   - Use "submitted" when confirmation is pending
   - Use "completed" only when verified
   - Use "failed" with specific error details
   - Never use checkmark emoji for unverified operations

The key changes:

Rule 1: Parse Response Bodies

agent_verification.py
def publish_article(self, article, platform):
    response = platform_api.publish(article)


    # Parse response body for explicit status
    if response.get("status") == "published":
        return {"status": "published", "article_id": response["id"]}
    elif response.get("status") in ["pending_review", "processing"]:
        return {
            "status": "submitted",
            "task_id": response.get("task_id"),
            "message": "Article submitted for review"
        }
    else:
        return {"status": "failed", "error": response.get("error")}

Now the agent checks response["status"] explicitly. “pending_review” gets reported as “submitted,” not “published.”

Rule 2: Read Back File Contents

For file operations, I added verification:

file_verification.py
def write_config(self, filepath, content):
    # Write file
    with open(filepath, 'w') as f:
        f.write(content)


    # Read back and verify
    with open(filepath, 'r') as f:
        actual = f.read()


    if actual == content:
        return {"status": "completed", "filepath": filepath}
    else:
        return {
            "status": "failed",
            "error": "Content mismatch after write"
        }

The agent doesn’t assume success. It reads back and compares.

Rule 3: Handle Async Operations

For publishing to platforms with async workflows:

async_publishing.py
def publish_with_polling(self, article, platform):
    # Submit article
    response = platform_api.publish(article)
    task_id = response.get("task_id")


    if response.get("status") != "pending_review":
        return {"status": "submitted", "task_id": task_id}


    # Poll for completion
    for _ in range(10):  # 10 attempts
        time.sleep(6)  # Wait 6 seconds
        status = platform_api.get_status(task_id)


        if status == "published":
            return {"status": "published", "article_id": task_id}
        elif status == "rejected":
            return {"status": "failed", "reason": "rejected"}


    return {"status": "pending", "task_id": task_id, "message": "Still processing"}

The agent now polls until it gets a definitive answer or times out.

Rule 4: Precise Language

The most important change was language discipline:

output_examples.txt
CORRECT:
"Article submitted for review. Task ID: abc123. Current status: pending_moderation.
Check back in 5 minutes or use task ID to poll status."


WRONG:
"Article published successfully!"

No more optimistic language. No more checkmarks for unverified operations.

Results After Adding Verification Rules

The behavior change was immediate:

  1. Agent reports “submitted for review” instead of “published”
  2. Orchestrator knows task is pending, not complete
  3. Downstream agents don’t assume article is live
  4. Human gets accurate status for intervention

Here’s the orchestrator log after the fix:

orchestrator_log.txt
[10:30:01] PublisherAgent: Article submitted for review
[10:30:01] Task ID: abc123
[10:30:01] Status: pending_moderation
[10:30:01] Orchestrator: Marking task as "pending confirmation"
[10:36:15] PollingAgent: Checking status of task abc123
[10:36:15] Status: published
[10:36:15] Orchestrator: Marking task as "completed"

The orchestrator now has accurate information to make decisions.

Common Mistakes to Avoid

Mistake 1: Assuming Agents Will “Figure Out” Verification

vague_prompt.md
You are a helpful assistant. Use the available tools to complete tasks.
Always be accurate and helpful.

This doesn’t work. “Accurate” is subjective. Be explicit about what accuracy means.

Mistake 2: Adding Rules as Afterthought

Don’t bury verification rules in a footer. Make them core instructions at the top level of your prompt.

Mistake 3: Vague Language

vague_instruction.md
Be careful when reporting status. Make sure to verify before claiming success.

“Careful” and “make sure” don’t tell the agent how to verify. Give specific actions:

specific_instruction.md
After API calls, check response.status field. If not "published", report "submitted" with task ID.

Mistake 4: No Examples

Abstract rules are harder to follow than concrete examples:

example_prompt.md
## Correct Output Examples


CORRECT:
"Article submitted for review. Task ID: abc123. Status: pending."


WRONG:
"Article published!"

Show the agent what you want.

Mistake 5: Not Updating Prompts for New Tools

When you add new tools or platforms, update your verification rules. A new API might have different response structures.

Why System Prompts Matter for Reliability

Prompt engineering is behavior engineering. Every instruction you add (or omit) shapes how the agent interprets the world.

Without verification rules:

  • Agent assumes HTTP 200 = success
  • Agent trusts surface-level signals
  • Agent uses confident language without evidence

With verification rules:

  • Agent parses response bodies
  • Agent reads back file contents
  • Agent reports precise status
  • Agent polls async operations

The LLM is the same. The tools are the same. Only the instructions changed. But the behavior transformed from optimistic assumption to verified confirmation.

When to Use These Rules

Apply verification rules when:

  1. Multi-agent systems - Downstream agents depend on accurate status
  2. Async workflows - Operations take time to complete
  3. External platforms - You don’t control the API behavior
  4. Audit trails - You need accurate logs for debugging
  5. Human-in-the-loop - Humans need accurate status to make decisions

For simple, synchronous operations with immediate feedback, you might not need all these rules. But when in doubt, verify.

Summary

LLM agents do exactly what their prompts imply. If you want verified confirmations instead of optimistic assumptions, you need explicit verification rules:

  1. Parse response bodies for success fields
  2. Read back file contents after writes
  3. Poll async operations until completion
  4. Use precise language - “submitted” not “completed”

These rules shift agent behavior from “trust the tool” to “verify the outcome.” Reliability starts with clear instructions.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: