Most AI agent demos stop at “ask, answer, repeat.” An operator needs something sturdier: a daily loop that turns intent into checked work, knows when to escalate, and leaves enough memory for tomorrow’s run. The goal is not maximum autonomy. It is dependable progress with a clear handoff when the agent reaches the edge of its authority.
Start with a job, not a chat
Give the agent one operational objective for the day. Examples: reconcile yesterday’s support backlog, prepare a release checklist, or turn a set of meeting notes into tracked actions. Define the finish line in observable terms: files changed, tickets updated, tests passing, or a review-ready report attached.
This is the “one-track EV” rule: optimize for expected value on one track at a time. Every extra objective adds branching, context switching, and more ways to silently drift.
A practical task brief has five fields:
- Outcome: what must be true when the run ends.
- Inputs: links, documents, APIs, and repositories the agent may use.
- Allowed tools: the smallest set needed for this job.
- Budget: time, tokens, tool calls, and any side-effect limit.
- Proof: the evidence a human can inspect before accepting the result.
The daily operator loop
Run the same sequence every day. First, orient: load the task brief, inspect the current state, and read the last run’s notes. Second, plan: break the objective into small actions and identify irreversible steps. Third, execute: use tools in short cycles, checking outputs instead of assuming success. Fourth, verify: run tests, compare counts, inspect diffs, and check that the result matches the brief. Fifth, report: summarize what changed, what was not attempted, and what needs a human decision.
The loop should be boring. Boring is observable. If the agent cannot say which step it is on, what it expects to see next, or why it is continuing, the run is probably too opaque to operate safely.
Escalation is a feature
Write escalation rules before the agent starts. Pause and ask for a human decision when an action is destructive, public, financial, security-sensitive, or outside the stated scope. Escalate when evidence conflicts, permissions are missing, a tool returns an unexpected schema, or the same recovery attempt fails twice. Also escalate when confidence is low and the cost of being wrong is high; confidence alone is not a safety policy.
Make the handoff useful. Include the exact decision needed, the options considered, the evidence collected, and the safest reversible next step. “I’m stuck” creates work for the operator. “The deployment check and the issue tracker disagree; here are the two records, the likely causes, and the command I will run if you approve” makes approval fast.
Separate read and write phases whenever possible. Let the agent gather facts and produce a proposed change before it performs a side effect. A human should be able to approve the proposal without reconstructing the entire run.
Memory that helps instead of haunting you
Treat memory as a compact operational record, not a transcript dump. At the end of each run, save four things: the objective and status, decisions and their reasons, verified facts with timestamps, and open questions or follow-ups. Link to source artifacts rather than copying huge payloads. Mark assumptions clearly and attach an expiry or re-check date to facts that can change.
On the next run, load only the relevant slice: the current brief, recent outcomes, unresolved escalations, and stable preferences. Then ask the agent to state its understanding before it acts. This catches stale context early and keeps the prompt small enough to inspect.
A useful memory entry might read: “2026-09-11: staging deploy passed tests but was not promoted; approval is still required from the release owner. Re-check status before planning.” That is more valuable than several pages of chat because it preserves state, provenance, and the next decision.
Measure the operator, not the theatrics
Track completion rate, verification failures, escalation quality, time to human decision, tool-call cost, and the percentage of work accepted without rework. Review a sample of runs weekly. Look for silent failures: plausible summaries with missing evidence, repeated retries, or tasks that finish “successfully” while leaving the real queue untouched.
A good agent is not the one that never asks. It is the one that advances routine work, shows its proof, remembers the right context, and asks at the right boundary. If you want a lightweight place to capture these operating patterns and turn them into repeatable workflows, see Nami Ops.
Start tomorrow with one track, one budget, and one explicit escalation rule. Let the agent earn more autonomy through verified results—not through optimistic settings.
Top comments (1)
The "finish line in observable terms" rule is the one most agent setups skip. Mine ran for weeks on a loop that defined done as "agent stopped", which quietly turned into "agent got bored". Rewriting each job's completion as verifiable side effects (file exists, API returns the new count, test passes) removed a whole category of false successes.
Curious how you handle the handoff artifact — does tomorrow's run read a structured state file, or the previous run's report? We use a JSON ledger that every action appends to, and it doubles as the anti-retry ledger.