Inside the Agent Worker: Dispatch, Execute, Report

Somewhere between "the agent is a chatbot" and "the agent runs my operations" sits a piece of machinery nobody demos because it's not photogenic: the **worker loop**. The thing that picks up a task at 6 AM, runs it to completion without a human typing anything, and leaves behind evidence of what it did.

This is a tour of that loop — dispatch, execute, report — as it runs in production, and the design decisions that separate a worker from a webhook with dreams.

Dispatch: work has to find the agent, not the other way around

Interactive agents are easy: a human shows up, pastes context, supervises. Autonomous work has no human to provide any of that. So dispatch carries three responsibilities:

**1. Claiming.** Tasks live in a queue with priorities, blockers, and scopes. The worker pulls the highest-priority claimable task — "claimable" meaning pending, unassigned, unblocked, and scheduled time reached. Atomic claiming matters: with several workers, two agents picking up the same task is a duplicate-PR incident waiting to happen.

**2. Hydration.** This is the step most agent demos skip. A task arrives as a subject line and a description; the worker must build everything the agent needs to not be useless: the project's conventions, the relevant memories, the last session's state, the linked feedback or roadmap items. One call assembles a token-budgeted context bundle — because an agent that starts empty will confidently reinvent decisions the project made months ago.

**3. Session binding.** The run opens a tracked session linked to the task and the dispatch job. Everything the agent does from here is attributable: this tool call, in this session, for this task, on this project. Attribution is cheap at dispatch time and impossible to retrofit.

Execute: the loop with a budget

Execution is a classic agent loop — model proposes tool calls, tools return results, repeat — wrapped in operational constraints:

- **Step and cost budgets.** Every job runs with a ceiling. A task that can't converge in N steps gets stopped and reported as stuck, not allowed to burn money exploring. Runaway agents are a billing incident before they're anything else.

- **Tool surface by scope.** The worker's tools resolve against the task's project: repo access, deploy tools, memories, conventions. Scope is enforced by the tool layer, so the agent physically cannot reach another tenant's resources — isolation by construction, not by instruction.

- **Checkpoints.** Long jobs save progress state periodically. A worker that crashes mid-task should resume from a checkpoint with its work items listed, not restart from a blank context and repeat the first hour.

- **Red-zone pauses.** When the agent hits an action outside its authority — a production secret, a destructive command — the loop doesn't fail; it *suspends*. The agent packages the request with evidence, files it to the approval queue, and the task waits on human. The gate is part of the loop, not an exception to it.

Report: the deliverable is the evidence

A finished autonomous task produces three artifacts, in order of importance:

**1. The audit trail.** Every tool call, every gate evaluation, every decision, hash-linked. If the task touched production, this is the proof of what happened and why it was allowed. It's written as the loop runs — not reconstructed afterward from logs and prayer.

**2. The structured outcome.** Success, failure, or blocked — plus the machine-usable residue: PR URLs, commit SHAs, files changed, follow-up tasks created. "Done" that downstream automation can't parse isn't done; it's a rumor.

**3. The synthesis note.** A short, evidence-backed account of what was accomplished and what was learned. The best ones feed the self-improvement loop: recurring failure patterns become convention candidates, recurring successes become templates. The worker doesn't just finish tasks; it makes the next dispatch smarter.

The failure modes that shaped this

Each constraint above is a scar. Budgets exist because an early worker spent a whole night retrying a malformed API call. Atomic claiming exists because two workers once opened identical PRs forty seconds apart. Red-zone suspension exists because "ask the model to be careful" turned out, predictably, not to be a security boundary. Checkpointing exists because a deploy restarted a worker ninety minutes into a two-hour migration.

Autonomous execution isn't a model problem. It's a reliability-engineering problem where the unreliable component happens to be very, very good at explaining itself.

The summary

Dispatch builds the context, execution respects the envelope, reporting leaves the evidence. Get those three right and "the agent did it overnight" stops being a pitch and becomes a Tuesday.

---

*Part of the FlukeBase supervised-autonomy series. Next: audit trails for autonomous systems — proving what your agents did.*