Comma

Where should my AI agent post its work?

You've got an agent that produces useful HTML — an analytics digest, an eval report, a release note, a customer summary. Now you need to decide where it lands.

Most teams pick one of four answers, and most of them have structural problems. This is a walkthrough of the options.

Option 1: A Slack channel

The setup: The agent generates the report, posts a screenshot (or a text summary, or a link to a temporary URL) into a team Slack channel.

Why it's the default: Zero infrastructure. The channel already exists. Everyone reads Slack.

Why it falls apart:

  • Feedback scatters across thread replies. Whoever spots an issue leaves a reply on the Slack message; whoever spots a different issue leaves theirs on a different reply. There is no canonical thread per report.
  • The artifact has no permanent home. Next week's run replaces last week's. Six runs in, the channel is a wall of similar-looking screenshots and nobody can tell which one was the source of the decision.
  • Comments aren't anchored to content. Slack threads attach to a message, not to "the row in the funnel table that dropped 8% in week 3." Feedback loses its anchor.
  • The agent can't read the feedback. A Slack integration can read channel messages, but mapping a Slack reply back to "this is feedback on the report's third paragraph" is a project. Most teams skip it.

When it works anyway: As a notification layer that says "the report is ready, here's the link to the actual surface." Not as the surface itself.

Option 2: An S3 bucket

The setup: The agent uploads the rendered HTML to a static S3 bucket behind CloudFront. The team gets a URL.

Why it's appealing: Fully under your control. Cheap. Stable URLs if you version your filenames.

Why it falls apart:

  • There's no UI for the team. S3 is storage, not a workspace. A URL to raw HTML is not a place reviewers will open by habit.
  • No comment layer. You can build one — a third-party annotation tool, or a custom comment service — but now you're maintaining two things.
  • No access control beyond URL secrecy. If the link leaks, the report leaks.
  • No revision concept. Either you overwrite the file (and lose history) or you version the filename (and reviewers can't tell which one is current).
  • The agent has no read path back. The agent posted; the team responded somewhere; the agent can't connect those signals on its next run.

When it works anyway: As an internal cache for an asset the agent will embed elsewhere. Not as the surface the team interacts with.

Option 3: A custom webhook + comment thread

The setup: You build a small service that receives HTML from the agent, renders it on a page, and includes a comment widget (maybe Disqus, maybe homegrown).

Why it's appealing: Fits your team's exact needs. Open-ended.

Why it falls apart:

  • You now own infrastructure. Auth, rate-limiting, comment storage, access control, audit log, notifications, mobile-friendliness, security patches.
  • It looks like a side project — because it is. The team's trust in the surface tracks the surface's polish. A side project doesn't get the polish budget.
  • The agent has to integrate against your custom comment API. Whatever you build, the agent now has bespoke tools to learn. New agent, new integration work.
  • One incident later, you're a comment-system maintainer. The original reason you built the agent quietly moves to second priority.

When it works anyway: If the report itself is highly bespoke and the shape of the team's interaction is unusual. Most teams' interaction is "render HTML, leave anchored comments, reply on the next run." That shape is general.

Option 4: Email

The setup: The agent emails the HTML or a PDF to a distribution list.

Why it falls apart:

  • Email has no comment layer. Replies go to whoever replies-all, in whatever inbox shape, with no connection to the artifact.
  • The artifact is a snapshot, not a document. Next week's email is a different email. There is no "the report" — only "the report you got on the 14th."
  • The agent can't read responses. Inbox-watcher integrations exist; none of them map a reply back to "the eighth paragraph" of the email.

When it works anyway: As a digest summary for stakeholders who don't need to comment. Not as the working surface.

What an agent posting surface should actually do

Six properties, working backwards from what an agent loop needs to close:

  1. Faithfully render the HTML the agent generated. No reformatting, no restyle. The agent's output is the truth.
  2. Stable URL across revisions. Reviewers bookmark the report; the next run replaces its content under the same link.
  3. Anchored comment layer. Comments pin to specific text or table cells inside the rendered HTML. The agent can read which text the comment refers to.
  4. One scoped, revocable credential. The agent's auth is one token that you can revoke without touching the rest of the workspace.
  5. Bounded cost when the agent runs on a schedule. Cron-style runs hit a refused-overflow cap rather than draining a budget.
  6. A read path back. The agent's next turn can list_comments and respond to specific anchored threads, not infer feedback from prose.

Each of the four options above is missing at least three of these. Most teams realize this around the second or third quarter of running their "working" agent, when the surface they bolted on is the thing keeping the agent's output from becoming meaningful.

What Comma does, briefly

Comma was built for exactly this loop:

  • MCP server at /api/mcp with the report and comment primitives as typed tools. The agent calls create_report, update_report, list_comments, add_comment, reply_to_comment.
  • Anchored comments on text and table cells inside the rendered HTML — the agent's next turn reads the selected text the comment refers to.
  • Stable URL per report. Revisions append; the share link doesn't change.
  • Scoped comma_sk_… token that gates the REST API, the MCP server, and any routines created under it. One revoke pulls everything.
  • Routines for scheduled runs with per-plan Bedrock caps that refuse to overflow.
  • Opaque-origin sandbox so the HTML the agent renders can't reach into the user's Comma account.

It's sharply scoped: Comma posts to a Comma report. It doesn't pretend to be a Slack-replacement, an email tool, or a general-purpose workflow runner. The narrow scope is the point — the loop is render → comment → read → respond, and that's the loop the agent and the humans share.

How to decide

A simple rubric:

  • One-off, low stakes? Slack is fine.
  • The team should bookmark a single working surface? Not Slack, not email. Either build the surface yourself, or use one built for this.
  • You have an agent that should read its own feedback? You need anchored comments and an MCP-native posting layer. That's Comma or something with the same shape.
  • You'll run this on a schedule for months? You need bounded cost and a revocable credential alongside the surface. Don't put this on a Mac mini.

Try the Comma shape

Free tier is enough to feel the loop end-to-end: three commenters per report, monthly routines, full MCP access, full anchored commenting.

Install the Claude Code plugin or create your first report →.

Related