Adding Email to an Autonomous Agent Loop

A cron-triggered job wakes up, checks mail, and exits — fine for anything that doesn't need to react within seconds. That pattern is the right default for a lot of workloads. An autonomous loop is the other architecture: a process that keeps running, repeatedly planning an action, taking it, and observing the result, for as long as the task requires. Adding email to that loop means adding two new actions to whatever action space it already has — and, unlike most actions in a typical agent loop, both of them cost real money per call.

Two actions, two different risk profiles

A free action is a bad call; a paid action is a bad call that also shows up on an invoice. check_inbox is free and read-only, so there's little harm in a loop calling it defensively on most iterations just to see if anything changed. send_inbox_email and the drafting call both cost money every time — charging in cents changes how an agent behaves in ways a free action never would, mainly because every call is now a decision with a price tag attached, not just a decision.

A minimal loop skeleton

import time
import httpx

ACTIONS = {
    "send_email": send_inbox_email,   # paid - wraps the 402 pay-and-retry loop
    "check_inbox": check_inbox,       # free
    # ...whatever other actions this agent has
}

def run_loop(agent_state):
    while not agent_state.done:
        action_name, args = plan(agent_state)  # your own LLM call

        if action_name not in ACTIONS:
            agent_state = observe(agent_state, error="unknown action")
            continue

        try:
            result = ACTIONS[action_name](**args)
        except httpx.HTTPStatusError as exc:
            # a 402 here means the signer or wallet couldn't cover the call -
            # DimeBox never charges for the failed attempt itself
            result = {"error": str(exc)}

        agent_state = observe(agent_state, result)
        time.sleep(1)

The send_email and check_inbox functions here are the same tool implementations covered in the Python quickstart — nothing about wiring them into a loop instead of a LangChain or CrewAI tool changes how they talk to DimeBox.

Guarding against a loop that sends too much

A loop that's misreading its own goal, or stuck re-planning the same step, can call a paid action far more than any reasonable task requires. Prompt engineering helps, but it's not a hard limit — the hard limit is a daily spend cap on the wallet or signer funding this loop, set once from the wallet dashboard and left alone. It's cheaper insurance than trying to perfectly anticipate every way a loop might misbehave.

Checking mail without blocking the loop

Because check_inbox is free and fast, it's safe to call on most iterations without worrying about cost — the loop can treat "did anything arrive" as a near-free observation, the same way it might check a local variable. Reserve actual deliberation for what to do with a new message, not for whether checking was worth the cost of checking.

The loop's own cost is separate from DimeBox's

It's worth keeping two different bills distinct in your head when you're costing out a loop like this: what the model itself costs to run (inference, per planning step) and what DimeBox charges for the email actions it decides to take. A loop that plans for ten iterations before sending a single email has spent ten rounds of inference cost and exactly one send's worth of DimeBox cost. Conflating the two makes it harder to tell whether a loop is expensive because it's indecisive (a prompting problem) or because it's genuinely doing a lot of paid work (a scope problem) — they call for different fixes.

What a dry wallet or signer looks like mid-loop

If whatever's funding this loop runs out partway through a task — balance hits zero, or a card on file for auto-reload gets declined — every subsequent paid action fails the same way a first-attempt 402 would, and the loop needs to treat that as a distinct terminal state rather than just another retryable error. A loop that doesn't recognize "I'm out of money" as different from "that one call failed" will keep re-planning the same paid action forever, discovering the same failure every time. Logging every paid action's status code and amount as it happens — not just the failures — gives you the trail to tell these cases apart after the fact, instead of reconstructing what happened from whatever's left in the agent's own transcript.

Budgeting the whole loop, not just one call

A single email costs a few cents; a loop that runs for hours and checks mail dozens of times, drafts a handful of replies, and sends a few, adds those costs up across the whole run. Budgeting for a fleet of autonomous agents covers the same math at a larger scale — the per-call prices are the same ones from the API reference, just multiplied by however many iterations a given loop actually takes to finish its task.