Key takeaways
Key takeaways

Key takeaways

What this agent does

Coda is the only working surface for some teams. Specs, OKRs, sprint plans, retros, customer notes, all of it lives in Coda docs. Over a week the team writes a lot, decides some things, and updates a few status fields. At the end of the week nobody quite knows what happened across the docs they did not personally touch.

The agent solves that. Every Friday afternoon, at a time you set, it calls the Coda API for each whitelisted doc and pulls the changes from the past seven days. It groups those changes into three buckets, writes one rollup page in a destination doc, and embeds links back to every source row. The team reads the rollup over the weekend or first thing Monday. The questions that come up Monday morning are now about decisions and blockers, not about what shipped.

What the agent does not do: it does not move rows between tables, change statuses, complete tasks, or assign owners. The destination doc gets one new page per Friday and the source docs are untouched. The audit trail of edits is left to Coda's own version history. The pattern lines up with how to limit an agent's actions, restrict the write surface to one place.

Sources of truth

Coda only. The agent does not import Linear tickets, Slack threads, or Notion pages, even when source docs reference them. Pulling external context to enrich the rollup makes it longer, not better.

The agent does not read row content for sensitive fields you mark private in the rubric. Common examples are salary tables, customer health scores, and legal exposure trackers. Those are skipped during the read step, not redacted in the rollup. Skipping is safer than redacting because nothing about the row enters the agent's context.

Three buckets, one page

The rollup has three buckets. Every change goes into exactly one. The buckets are chosen because each one demands a different response from the reader.

Nothing else makes it into the rollup. Inline page edits, prose changes, comment threads, scratch tables that are not whitelisted. All ignored. The constraint comes from running the first version with five buckets and noticing that nobody read past the third. Three buckets matches what readers actually do. The same observation shows up in the founder write-up at how I pick what to build next.

Output: the Friday rollup page

The destination doc is named whatever you want. Most teams call it Rollups. Each Friday the agent creates a new page in that doc dated for the week, like "Week of 2026-05-18 to 2026-05-22, Rollup". The page structure is fixed.

  1. Preamble. Two lines. Docs scanned this week. Any new docs added since last week.
  2. Decisions. Bulleted list. Each line shows the decision, the doc, and a deep link to the source row.
  3. Updates. Grouped by doc. Each doc gets a sub-heading and a bulleted list of status moves.
  4. Blockers. The only bucket where the agent picks a default sort. Oldest blockers first. Each line shows the blocker, the owner, the age in days, and a deep link.
  5. Tail. One line. Total rows scanned, total changes captured.

That is the entire page. No charts, no week-over-week comparisons, no AI commentary on whether the team is "on track". The reader looks at the page, decides what matters, and acts. The agent stops at writing. For the deeper reasoning behind that, see describe the outcome, not the workflow.

Guardrails

Two guardrails make this agent safe in a multi-person workspace.

Beyond those two, the agent rate-limits its Coda API calls below the published quota (every Coda workspace has a generous limit, but a Friday burst across twelve docs is worth pacing). It writes the rollup in a single API call per page, not row-by-row, to keep the destination doc's version history clean.

Common mistakes

Including prose pages in the rollup. Early versions tried to summarise every page edit. The result was a rollup with five paragraphs of "this spec got an edit" entries that nobody read. Now prose pages are out by default. If a spec includes a decision, the team is expected to record it in the Decisions table.

Rolling up daily. A daily rollup gets ignored after a week. Weekly is the right interval because most decisions and blockers have a half-life longer than a day. If your team genuinely moves at daily cadence, the agent runs daily, but the experience suggests that even very fast teams find Friday is enough.

Whitelisting too many docs. Twelve is the practical ceiling. Beyond twelve the rollup turns into a directory and stops being a digest. If a workspace has thirty active docs, the right move is two rollups for two audiences, not one rollup with everything.

Letting the agent write into source docs. The first version had a flag for "write the rollup back into the source doc as a comment". Nobody used it and it caused permissions confusion. Now the rollup lives in one place. If you want to link back from a source doc, link from the source manually, once per quarter is enough.

Skipping the preamble. The two-line preamble that names the docs scanned matters more than it looks. When the rollup is short, the preamble tells the reader whether it is short because the week was quiet or because a doc was missing. That distinction is the same one that how to monitor agent activity argues you should always preserve.

Frequently asked questions

Can an AI agent roll up changes across multiple Coda docs?

Yes. The agent uses the Coda API to read the docs you whitelist, fetches changes from the past seven days, and writes one rollup page in a destination doc you nominate. It groups changes by doc, by table, and by author. The whole rollup fits on a single Coda page that takes under five minutes to read.

Does the agent need write access to every Coda doc?

No. It needs read access to the source docs and write access only to the destination doc that holds the rollup page. Source docs are never modified. This separation is intentional. Read scopes are easier to grant across a workspace and the rollup lives in one place you control.

What does the agent count as a meaningful change?

New rows in tracked tables, status field transitions, owner field changes, and any row marked decision or blocker. Inline edits to existing prose pages are not counted unless the page title contains a tracked keyword like Decisions, Status, or Blockers. The keyword list is configurable per doc.

How does the agent handle private Coda docs?

If the agent's service account does not have access to a doc, the doc is ignored. There is no escalation path. To include a private doc, share it explicitly with the agent's service account at read level. The rollup will note that the doc was newly included in the next run's preamble.

Can the rollup replace our weekly status meeting?

It can replace the part of the meeting where people read updates aloud. It cannot replace the part where the team discusses tradeoffs and makes decisions. Teams that move to the rollup typically keep a thirty-minute weekly call focused only on items the rollup flagged as blocked or undecided.

Three takeaways before you close this tab

  1. Three buckets, weekly, one page. Anything more than that gets ignored by the third week.
  2. Read scopes everywhere, write scope nowhere except the destination doc. Permissions are the guardrail.
  3. The rollup is for what shipped. The meeting is for what to decide. Keep both, shrink the meeting.

Sources