Give a NoInfra Agent a Recovery Plan Before It Runs Unattended

The first useful NoInfra agent is usually narrow: one source, one job, one owner, one review path. That is enough to prove the loop. It is not enough to leave the agent unattended.

Unattended work changes the failure mode. A manual first run can be stopped by the person watching it. A recurring or always-on agent may fail between reviews, after an input changes, after a tool permission changes, or after a token boundary is hit. The question is not whether the runtime can keep running. The question is whether the team can return the workflow to a known-good state without guessing.

Before a NoInfra agent runs unattended, write a recovery plan. It does not need to be long. It needs to answer five practical questions: who owns recovery, what counts as the last good state, what gets paused, what gets replayed, and what proof shows the agent is healthy again.

Start with the recovery owner

Every unattended agent needs one recovery owner. This is not the same as the person who requested the agent. It is the person who can make a decision when the agent produces bad output, stops responding, exhausts its run budget, or needs a source reconnected.

Write the owner into the handoff:

• Who gets notified when the agent misses a run?
• Who can pause the workflow?
• Who can approve a replay?
• Who decides whether the agent keeps running, narrows scope, or retires?

If those are four different people, the agent is not ready for unattended work. NoInfra can remove server setup, provider-key setup, and runtime chores, but it cannot remove the need for an accountable operator.

Define the last good state

Recovery starts with a known-good point. For a NoInfra agent, that point is usually not "the deployment succeeded." It is the last run where the input, output, review, and downstream action were all understood.

Use a simple format:

Last good run:
- Input source:
- Run time:
- Output location:
- Reviewer:
- Accepted result:
- Downstream action taken:
- Known exclusions:

This prevents the team from treating a green runtime state as a business-state recovery. An agent can be ready, reachable, and still recovering from the wrong place. The recovery plan should tell the owner what work was trusted last, what was explicitly excluded, and which source record should win if two records disagree.

Decide what pauses first

The safest recovery plan is specific about what stops automatically or manually. Do not write "pause the agent" and leave it there. Name the actual surfaces.

For many first NoInfra workflows, the pause order looks like this:

1. Stop new unattended runs.
2. Preserve the current logs and output receipts.
3. Leave source systems untouched unless an approved action is required.
4. Stop downstream notifications if they could confuse users or teammates.
5. Keep manual review open so the owner can inspect the last attempt.

That pause order matters. If the team deletes the evidence while trying to fix the agent, recovery becomes reconstruction. If the team lets downstream actions continue while investigating, the incident can spread from one bad run into a messy operational cleanup.

NoInfra's hosted runtime helps because the agent does not depend on a laptop, local process, or personal API keys. The recovery plan should use that advantage: keep the runtime evidence available, pause the loop, and make the next decision from receipts instead of memory.

Separate token recovery from workflow recovery

Managed server-side tokens reduce provider-key setup, but they do not remove the need for a token boundary. When an unattended agent stops because it reaches a spend or token limit, the wrong response is to reload first and ask questions later.

Put a token recovery rule in the plan:

• If the run stopped before producing a reviewable output, inspect the prompt, input size, retry behavior, and tool calls before adding budget.
• If the run produced partial output, decide whether partial work is useful or should be discarded.
• If retry behavior consumed the budget, narrow the input or add a stop rule before the next run.
• If the workload is now consistently larger than the plan, upgrade only after the owner confirms the workflow is worth scaling.

This keeps billing and operations separate. The goal is not to avoid spending tokens. The goal is to spend them on a workflow that is understood, reviewable, and still pointed at the right job.

Build the recovery path before the first unattended run. Start a NoInfra agent from the create-agent flow, keep the first workflow narrow, and add the owner, last-good-state, pause, replay, and token rules before it runs on repeat. Create an agent on NoInfra.

Write the replay rule

Most teams skip replay until something breaks. Then they discover they do not know whether to rerun the same input, patch the input, skip the failed item, or manually complete the work.

Write the replay rule while the workflow is still calm:

Replay rule:
- Replay only from the last good input checkpoint.
- Do not replay outputs already accepted by a human.
- Do not replay if the source-of-truth record has changed without owner review.
- Mark any manual completion so the agent does not duplicate it.
- After replay, compare output against the accepted format before restoring unattended runs.

The replay rule protects the team from duplicate messages, duplicate records, stale source data, and false confidence. It also gives the owner a clear way to restore the workflow without turning the recovery into a new project.

Require proof of repair

Recovery is not complete when the agent starts again. Recovery is complete when the agent produces a new reviewable result from the right input, under the updated boundary, and the owner accepts it.

The proof can be simple:

• A successful run receipt.
• The input source and timestamp.
• The output location.
• The reviewer or owner who accepted the result.
• The exact rule changed during recovery, if any.

That proof is what lets a NoInfra agent graduate from "we restarted it" to "we know it is doing the right work again." It also gives the team a record for the next scope decision. If the same recovery path is used repeatedly, the workflow may need a narrower input contract, a stricter stop rule, or a different runtime fit.

Keep the plan short enough to use

A recovery plan that nobody reads is not a recovery plan. Keep it close to the agent handoff and make it operational:

• Owner: one person.
• Last good state: one accepted run.
• Pause rule: what stops first.
• Token rule: when to inspect before adding budget.
• Replay rule: what can be rerun safely.
• Repair proof: what must be true before unattended work resumes.

NoInfra is useful because it gives builders a hosted path to real agent work without provider-key setup or server setup. The recovery plan is what lets that work continue past the first demo without becoming fragile. Before the agent runs unattended, write down how to bring it back.

Ready to move one workflow from manual test to hosted runtime? Create a NoInfra agent, start with one narrow job, and attach the recovery plan before you let it run unattended. Create an agent on NoInfra.