Build a Weekly Personal-Agent Digest You Can Audit, Not Just Admire

#productivity #agents #tooling #ai

Riley Brown shared a workflow with an unusually useful final product: connect an agent to your X activity and turn the previous seven days into a personal weekly digest. The steps in his original post were concrete: inspect recent posts and saved items, connect related ideas, group them by theme, retain original links, organize the result with headings, and use historical writing to reflect the user’s voice and opinions.

The appeal is not “AI can write a newsletter.” It is that two streams reveal different parts of a week. Your posts show what you chose to say. Saved material shows what you wanted to revisit. A digest can connect them into a record of attention.

The source post received more saves than likes in the captured snapshot, which is a useful clue that readers treated the workflow as reusable. It is not proof that the integration works for every account. A commenter reported that the X API connection was unavailable, so access has to be an explicit product dependency rather than a promise hidden inside the prompt.

Make the input ledger the product’s source of truth

Do not let the model read a timeline and immediately emit prose. First create an immutable activity ledger. An illustrative record could look like this:

{
  "item_id": "x:2088735501985665245",
  "kind": "authored_post | saved_item",
  "actor_id": "user:123",
  "original_author_id": "user:456",
  "url": "https://x.com/...",
  "published_at": "2026-08-15T21:12:05Z",
  "saved_at": null,
  "text_hash": "sha256:...",
  "ingestion_run_id": "week:2026-W33:v1"
}

This schema is illustrative, not code I have run. Its most important decision is the kind field. Authored posts and saved work must never collapse into one pool, because that is how an agent can accidentally write another person’s claim in the user’s voice.

Use a stable item_id derived from the platform and source ID. Make ingestion idempotent: importing the same week twice should update known metadata or do nothing, not duplicate half the digest. Store the original URL and a content hash so edits or deletions can be detected instead of silently rewritten in history.

Put a checkpoint between every transformation

A weekly digest becomes auditable when each stage produces a durable artifact:

Access checkpoint: record the authorized source and the exact retrieval window.
Ingestion checkpoint: persist the raw item IDs, URLs, timestamps, authors, and item type.
Normalization checkpoint: extract comparable text while retaining the raw reference.
Theme checkpoint: store the cluster or label assigned to every item, including ungrouped items.
Draft checkpoint: map each generated paragraph to the item IDs that support it.
Verification checkpoint: test links and flag sentences with no supporting source.
Delivery checkpoint: save the final digest version and the run that produced it.

OpenTelemetry’s trace model is a practical analogy: a trace contains spans with parent-child relationships, timestamps, attributes, events, and status. A digest run can use the same structure, so a failed link check does not look like a failed ingestion and a partial rerun does not erase the successful stages.

For cross-system provenance, the W3C PROV-O recommendation provides a more formal vocabulary for entities, activities, and agents. A small product does not need to adopt the full ontology. The useful idea is simpler: preserve which source entity was used by which transformation to generate which paragraph.

Generate from evidence packets, not a loose corpus

After grouping, build one evidence packet per theme. Each packet should contain:

the theme label and why the items belong together;
authored posts in chronological order;
saved items in a separate section with their original authors;
source URLs and timestamps;
contradictions or weak connections the model must not smooth over;
a word budget and desired form for the final section.

Then ask the model to draft only from that packet. Require paragraph-level citations internally even if the published digest uses a cleaner “Sources” line below each section. A sentence that cannot name its supporting item should be removed, rewritten as interpretation, or marked for human review.

Voice grounding should also be bounded. Historical posts can supply diction and recurring interests, but they do not authorize the model to invent a position. Keep style examples separate from weekly factual evidence. A digest can sound like the user while still saying, “I saved three arguments about this and have not reached a conclusion.”

Design for unavailable or partial access

As checked for this draft on August 17, 2026, X’s current API documentation lists post timelines, liked-post lookup, and authenticated bookmark retrieval under its pay-per-use API. The bookmark endpoint is the closest match to the source post’s “saved items” input and requires a developer account, an approved app, and user authorization. See the official X API overview, Likes endpoints, and Bookmarks endpoints. Pricing, scopes, and endpoint availability can change, so recheck them before implementation.

An official account archive can supply some historical account data when an API path is unsuitable; X’s help material says users can download an archive of their post history. Do not assume that archive contains every saved-item field you need. If saved items are missing, accept a separate user-authorized export or run with authored posts only and label the digest incomplete.

That degraded mode is better than quietly substituting a public search. Public search can miss protected, deleted, or unindexed activity and cannot prove what the user saved.

Evaluate the digest with recoverable questions

The first evaluation does not need a style judge. Ask questions with observable answers:

Did ingestion cover the requested seven-day window?
Does every item appear once, and in the correct authored-or-saved partition?
Does every source link open at verification time?
Can each factual paragraph be traced to one or more item IDs?
Did the model invent agreement between sources that actually conflict?
Can a failed verification stage rerun without re-ingesting the week?
Would the user keep or forward at least one section?

The prompt from the original post is still the hook because readers can imagine the finished email immediately. The engineering work begins one layer below it. The durable product is an activity ledger plus checkpoints and provenance; the prose is a reproducible view over that record.

Source list

AI-assistance disclosure: This article was drafted with AI assistance and manually source-checked and edited. The evaluation schemas are proposals, not implemented or benchmarked results.

DEV Community