Learn how to build reliable AI agent automations with persistent checkpoints, complete source coverage, verified delivery, scoped access and recovery tests.
A background AI agent can produce a convincing update while quietly missing half the work. A source may be unavailable, an API may return only its first page, or a message may be sent successfully just before the connection times out. None of those problems is solved by asking the model to write a better summary.
Reliable AI agent automations need a record of progress, a precise definition of completion and a way to recover when the outcome is uncertain. This guide develops those requirements through an illustrative release-status digest. The same design questions apply to recurring research, support summaries and project updates.
Start With a Responsibility You Can Verify
Anthropic’s automation walkthrough describes a scheduled assistant that reads Slack and GitHub, keeps bookmarks between runs and sends a concise brief. Its advice includes preserving progress when a source fails, checking current facts before publication, confirming delivery and separating user-controlled preferences from writable state. It is a useful starting point for understanding what an unattended agent must get right.
Our example is a daily digest for a software release manager. It should identify changes affecting the next release, show which decisions need attention and link to the underlying evidence. It may read two approved channels and one repository, then write to a single designated destination. It has no responsibility for merging code or notifying customers.
Write down what a successful run means before selecting a model. In this example, success means covering the agreed sources, producing a current and useful digest, saving the destination’s confirmation and leaving enough state for the next run. A readable paragraph is only one part of that outcome.
Separate Reading Progress From Delivery Progress
A useful checkpoint answers a specific question: up to which source position has the workflow safely handled the relevant information? A run log answers another: what happened during this execution? Neither should be replaced by the model remembering that it probably checked the repository yesterday.
Anthropic’s memory documentation explains how persistent stores carry information across otherwise fresh sessions. Stores can have different access modes, including read-only reference material and writable working state. The documentation also describes version history, which can help investigate a mistaken state change.
For our digest, a simple implementation can keep the last confirmed source positions unchanged until the digest is delivered. A more elaborate design could persist incoming records to a durable inbox first, then track ingestion and reporting separately. That second design needs two explicit checkpoints; saving an item locally must not falsely mark it as already reported.
For example, the system may have collected a pull request at 08:15 but still be waiting to publish the morning digest. Recording it as collected is reasonable if the record is durable. Recording it as delivered would be wrong. Name the states clearly enough that a replacement worker can resume without guessing what the previous agent meant.
Use stable source identifiers alongside timestamps. Two records can share a timestamp, and a record may be edited after it was first created. The exact checkpoint format should follow the source’s ordering and update semantics. A human-friendly date is useful for a report, but it is not always a sufficiently precise recovery key.
Read the Complete Result Set
A query can succeed while returning an incomplete collection. Slack’s pagination documentation explains that supported methods return portions of results and a cursor for requesting the next portion. It warns that receiving fewer items than the requested limit does not necessarily mean there are no more results.
GitHub’s REST guidance likewise explains paginated responses and following the links supplied by the API. A digest that reads a single page of a busy repository can therefore miss activity even when its time filter is correct.
Keep a pagination cursor distinct from a durable source checkpoint. A cursor helps traverse one result collection; a saved checkpoint defines where a later run should resume. Whether a cursor remains valid across later runs depends on the API, so do not assume the two concepts are interchangeable.
Test the release digest with more records than one page can hold. Put a release-blocking item near the beginning, middle and end of the fixture. The expected output should be determined from the complete fixture, not from whichever records the agent happened to retrieve.
Make Missing Coverage Visible
A source that contains no relevant changes is different from a source the agent could not read. Authentication failures, permission changes and service errors should be represented separately from an empty result. Otherwise, a manager may interpret an incomplete digest as evidence that a release is on track.
For our workflow, define three source outcomes: read successfully, read partially and unavailable. A successful empty read can support a statement that no relevant change was found within the covered range. A partial read supports only a statement about the portion actually inspected.
If GitHub is unavailable but both channels are readable, the digest might still be useful. Label it as partial and name the missing repository coverage. Preserve the unfinished checkpoint so a later run can recover the gap. If the missing source is essential to the decision, stop the publication instead; that choice belongs in the workflow’s policy.
Google’s monitoring guidance distinguishes internal instrumentation from checks of user-visible symptoms. Apply both perspectives here: record connector errors internally, but also check whether a complete digest reached its reader by the required time. A healthy scheduler does not establish that the useful output exists.
Verify the Claims That Drive Decisions
A digest should distinguish an observed event from a claim about the present. “The review was blocked at 08:00” and “the review is still blocked” require different evidence. The second statement needs a current status check, especially if the digest took time to prepare.
In our release example, build a small evidence record for each proposed line: source ID, source link, observed status and the time of the latest check. Before delivery, re-read decision-critical records. If a blocker has been resolved, update the line or remove it rather than issuing an unnecessary escalation.
Also distinguish freshness from completeness. Rechecking three selected items does not establish that the workflow found every relevant item. Collection tests address coverage; final status checks address stale claims. Both need to work for the digest to be dependable.
State how continuing issues should appear. A release blocker that remains open might deserve a short carry-forward line, while an unchanged routine item may not. Record the policy explicitly so the assistant does not confuse “already mentioned” with “no longer important.”
Treat an Uncertain Send as Its Own State
A network timeout does not tell you whether the receiving service performed the requested operation. Amazon’s idempotency guidance explains using a caller-provided request identifier so a service can recognize retries of the same operation. This capability must be part of the receiving API’s contract; generating a local identifier alone cannot make any endpoint safely retryable.
Slack’s posting API documents a successful response containing an OK value, channel and message timestamp. Save the relevant confirmation when it arrives. A log that says “sending” is evidence of an attempt, not evidence of delivery.
For the release digest, assign one edition identifier and record the intended destination before sending. If confirmation is lost, mark the edition uncertain and inspect the destination for the matching message. Use a delivery wrapper that supports idempotency where available; otherwise, reconciliation is part of recovery.
Do not promise exactly-once delivery merely because the agent searches recent messages first. Two overlapping workers can both search, find nothing and then send. Our proposed workflow should prevent overlapping publication attempts or use a durable claim on the edition. The important property belongs in the application’s coordination logic, not just its prose instructions.
Protect the Rules and Bound the Work
Keep the owner’s policy separate from the agent’s observations. Source lists, destinations and permission limits should not be casually rewritten while the agent summarizes an incoming message. In Managed Agents, the documented read-only memory mode provides a concrete mechanism for protecting reference stores rather than relying only on a request not to edit them.
OWASP describes excessive agency as unnecessary functionality, permissions or autonomy that can allow damaging actions. A release digest does not need a credential capable of deleting repositories. Narrow credentials and destination restrictions reduce what a mistaken or manipulated agent can do.
These limits do not guarantee that its text is correct. An incoming message could still influence a summary or contaminate writable notes. Our prompt injection guide explains why information from a source should not automatically acquire authority over the workflow.
Bound execution as well as access. Choose limits for elapsed time, tool calls and cost, and decide what a stopped run leaves behind. Anthropic’s deployment documentation separates the recurring schedule from the session it starts. Inspect actual run outcomes rather than treating the existence of a schedule as proof of completion.
For our example, a budget stop during collection should preserve the unfinished work and notify the owner through an agreed operational route. It should not publish a normal-looking complete digest. Measure ordinary and unusually busy runs before choosing limits; a ceiling that interrupts every busy morning defeats the purpose of the automation.
Test Recovery Before You Trust the Schedule
Begin with synthetic source records and a test destination. Run the digest manually, inspect its evidence and compare the result against known expectations. Then deliberately interrupt it at different stages. These are proposed acceptance tests for the example, not results from a product benchmark.
Start a run late and check that it covers the unfinished range without losing an item.
Return multiple pages and verify that the important item on the final page is considered.
Make one source unavailable and confirm that the output identifies missing coverage.
Resolve a blocker during preparation and check that the final digest reflects the new status.
Lose the send confirmation and verify that recovery checks the destination before another attempt.
Trigger two workers for one edition and confirm that only the authorized publisher can send.
Reach a run limit and check that the saved state supports a clear, safe recovery.
Keep the test expectations outside the agent’s own completion narrative. Inspect source checkpoints, the delivered message and the run record directly. The broader evaluation guide explains how to compare useful outcomes, supervision effort and repeatability.
Once the workflow behaves correctly, introduce a small live scope and review its first runs. Expand sources or publishing authority one change at a time. The goal is an automation that can explain what it covered, prove what it delivered and resume unfinished work without quietly dropping it or doing it twice.
