My AI Agent Kept Missing Deadlines and Double-Posting — Here's How I Fixed It with JSON Interfaces and Idempotency Checks

Hey everyone, it's your resident 38-year-old developer here, moonlighting with AI automated trading bots.

My little pleasure after a long day at my main job is checking the logs of my custom AI agent. Every night, it analyzes a specific market and records its preliminary trading decisions in JSON format. Pretty smart little helper, usually.

But one morning, checking the logs as usual, I found a mess:

• Three identical trading decision records for the same date.
• Decisions that should have been logged by 23:59 the previous day were somehow being attempted at 2:30 AM, failing with a "deadline exceeded" error.

For a moment, I panicked, thinking the AI had bugged out and gone rogue. An agent designed for autonomous operation was repeating tasks and missing critical deadlines. This was a pretty serious situation.

Today, I want to share the nitty-gritty of how I prevented this "AI meltdown."

The Problem: AI Is Too Obedient, and Unaware of Execution Environment Quirks

Upon closer investigation, the AI itself hadn't gone crazy. The root cause lay in the overall "mechanism" that ran the AI agent.

My system was a simple setup: a Windows Task Scheduler would kick off a Python script at a fixed time every night, and that script would call an LLM (Claude) to generate the decision.

The problem arose when, for some reason, the Task Scheduler re-executed the task. For example, a brief network outage, or a slight delay in response due to machine load. In such cases, the OS might "helpfully" retry the task, thinking, "Oh, did that task fail? I'll just run it again."

The AI, however, knows nothing about these OS-level nuances. It simply received the command to "make a decision and record it," and dutifully went through its thought process from scratch each time, writing down the results. Even if I added "execute only once" to the prompt, it wouldn't prevent OS-level retries.

In essence, entrusting the entire "make a decision and write it down" process to the AI was the fundamental design flaw.

The Fix: Separating "Context Gathering" from "Decision Writing"

To address this, I clearly separated the responsibilities of the Python script (decide.py), which served as the interface to the AI, into two distinct parts.

Step 1: The AI retrieves "context" as JSON for its decision-making.

First, I created a --context mode, specifically for retrieving the information the AI needs to think.

py -3.12 C:/path/to/my/project/decide.py --context

Executing this command returns a JSON object to standard output, summarizing current market information, historical data, and so on. This command never alters the system's state, no matter how many times it's run. It just reads data. So, it's safe.

The AI agent first understands the current situation using this command.

Step 2: The AI writes its "decision result" in JSON format.

Next, I prepared a --write mode that simply accepts the AI-generated decision JSON and saves it to a file or database.

py -3.12 C:/path/to/my/project/decide.py --model claude-fable-5-1 --write '{"session_date": "2024-05-20", "decision": "buy", "reason": "...", "confidence": 0.85}'

The crucial part is that I implemented rigorous pre-write checks within this --write script.

# Part of decide.py (conceptual)
import argparse
import json
from datetime import datetime

def write_decision(data):
    # 1. Deadline Check
    session_date_str = data.get("session_date")
    session_date = datetime.strptime(session_date_str, "%Y-%m-%d").date()

    # If the deadline has passed, don't write and raise an error
    if datetime.now().hour > 23: # Example: 23:00 is the deadline
        raise ValueError(f"Deadline passed for session {session_date_str}")

    # 2. Idempotency Check (prevent duplicate writes)
    if record_exists(session_date):
        print(f"Record for {session_date_str} already exists. Skipping.")
        return # If it exists, do nothing and exit successfully

    # Only if all checks pass, execute the write operation
    save_to_database(data)
    print(f"Successfully wrote record for {session_date_str}")

# ... argparse handling for --context and --write ...

With this modification, even if the Task Scheduler mistakenly executes the command multiple times:

• First execution: Passes checks and writes successfully.
• Subsequent executions: The record_exists check identifies "already recorded" and finishes without doing anything.

The deadline check also blocks the write operation if the deadline has passed.

This property, where executing an operation multiple times yields the same result, is called "idempotency." By implementing this mechanism, I gained safe control over the AI agent's execution.

Lesson Learned: Designing AI Autonomy and Its Control Boundaries

The key takeaway from this failure is that if you're giving an AI agent autonomy, you absolutely must design "safe execution boundaries" from the human side.

• Clearly separate read operations (reading state) from write operations (changing state). This is fundamental to Web API design, and it applies perfectly to AI agent integration.
• All write operations must be idempotent. AI and its operating environment might not always behave as expected and execute only once. It's essential for the receiving end to control the system, ensuring it doesn't break no matter how many requests it receives.
• Let the AI focus on "thinking." Procedural tasks like deadline checks or duplicate submission prevention are more reliable and cost-effective when handled by external programs rather than trying to force them into AI prompts.

Delegating tasks to an AI might be similar to assigning work to a smart new hire. They're capable, but they don't know all the operational rules or company culture. So, before allowing critical operations, always establish double-check and permission-setting mechanisms.

Developing AI agents isn't just about clever prompt engineering; it's about building up these subtle interface designs and error handling practices that are key to stable operation. This incident truly drove that point home for me.

---

I build and run small Python systems — trading bots, RAG APIs, scheduled automation — and write up whatever breaks along the way.

If a provider-agnostic RAG Q&A API is useful to you, mine is MIT-licensed on GitHub: rag-faq-api. It runs and passes its full test suite **with no API key* (offline stub LLM + hashing embedder), swaps to Claude / Gemini / OpenAI via one env var, and ships a retrieval-quality harness (Hit@k / MRR / Recall@k) with a chunking sweep.*