Comma

Hosted cron for AI agents

You have an agent. It produces useful output. Now you need to run it on a schedule, reliably, with bounded cost, into a surface humans will actually open — and you don't want to build that infrastructure.

Comma routines are that infrastructure.

The thing nobody mentions about agent ops

Writing an agent that produces a useful report once is the easy part. The hard parts are operational:

  • Where does it run? Lambda, GitHub Action, Cloud Run, your laptop?
  • How often, exactly? Cron expression, jitter, retry on failure, dedupe.
  • What does it cost? Token bills are not bounded by default. One bad prompt can drain a month's budget in twenty minutes.
  • Who holds the credential? Where is the API key, who can rotate it, what happens when it leaks.
  • Where does the output go? Slack channel, S3 bucket, internal site, email — all destinations the team won't reliably open.
  • How does feedback get back to the agent? Anchored on what? Replied by whom? Read by which next run?

Each item is solvable. Doing all of them yourself is how a side project turns into a quarter of ops work.

What routines collapse

Routines handle the whole shape under one configuration:

  • The schedule. Monthly, daily, hourly (Team), or sub-hourly (Enterprise). No cron daemon to maintain.
  • The execution. Comma runs the skill on its own infrastructure against AWS Bedrock — either through Comma's billing rail or your own keys (BYOK, Team plan).
  • The cost ceiling. Per-plan monthly Bedrock caps. Per-run safety caps. Refuses rather than overflows.
  • The credential. A scoped comma_sk_… token. Revoke once and the schedule, the agent, the REST API, and the MCP server all stop simultaneously.
  • The posting surface. The new HTML lands as a revision on a Comma report. Reviewers comment. The agent reads the comments on its next run.
  • The audit trail. Run history, per-run cost, success/failure, output diff — all visible per routine.

One token, one revoke

Comma's auth model is intentionally narrow. The same comma_sk_… token gates three surfaces:

  1. The REST API (/api/v1/*).
  2. The MCP server (/api/mcp).
  3. The routine itself (which executes under the token that created it).

If the token leaks — laptop lost, repo accidentally public, employee leaves — you revoke it once and the agent loses the routine, the API, and the MCP surface in one motion. There is no second credential to chase. There is no "oh but it also has a Slack webhook" to remember.

For an agent ops surface, this matters more than it sounds. Most agent incidents are credential incidents.

Bounded cost, by design

Routines refuse to overflow your plan's monthly Bedrock cap. The numbers:

Plan Monthly Bedrock cap Per-run safety cap Included credit
Free $0.50 yes —
Pro $15/mo $50 yes $5
Team $75/seat $300 yes $30
Enterprise Custom yes Custom

When the cap is hit, subsequent runs in the period refuse to execute and record a "capped" entry in run history. No emergency Stripe charge, no midnight email from finance.

Bring your own Bedrock keys (Team)

Team users can plug in their own AWS Bedrock keys. Two consequences:

  • Spend ships to your AWS account. Existing tagging, cost-allocation, and budget alerts already in place — they apply automatically. No new procurement surface.
  • No Comma markup on the Bedrock rail. You pay AWS what AWS charges.

The per-run safety cap still applies on BYOK, so a runaway prompt can't empty the account in one execution.

A posting surface humans actually open

Slack channels go unread. S3 buckets are not a UI. Email is where reports go to die.

Routines post into a Comma report — the same artifact the team already opens for review. The link is the same; only the revision counter advances. Anchored comments persist. Resolution state persists. The conversation lives on the artifact.

When the agent posts the next revision, reviewers see a diff against the previous one and can pin a comment on the exact line that changed.

How agents read the loop closing

Routines are agent-native in both directions:

  • The agent writes the routine. Through the REST API or the official Claude Code plugin's /comma-routine slash command. Same scoped token as the rest of the surface.
  • The agent reads the feedback. Comments left on previous revisions are visible to the agent on the next run via the MCP server's list_comments tool. The agent can reply through reply_to_comment under the same token, marking threads as addressed or asking a follow-up.

The loop — schedule → run → post → comment → reply → next run — closes without humans wiring it.

Setup

Either through the UI (Routines → New routine) or through the API:

curl -X POST https://commareports.com/api/v1/routines \
  -H "Authorization: Bearer $COMMA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "report_id": "rpt_…",
    "skill_body": "<markdown skill>",
    "cadence": "hourly",
    "cost_cap_per_run_usd": 0.50,
    "notify_on_revision": ["oncall@example.com"]
  }'

The MCP server today exposes report and comment primitives as typed tools. Routine creation runs over REST or the plugin's /comma-routine slash command — same scoped comma_sk_… token.

Who this is for

  • Agent operators running Claude/Cursor agents on a recurring task.
  • AI developers shipping eval harnesses that need to refresh daily.
  • Eng leads who want their team's "weekly bot script" off a laptop and on a scoped, capped rail.
  • Platform teams building internal agents that report into a shared workspace.

Try it

The same shape works on the Free plan with a monthly cadence — useful for proving the loop end to end before you move it to daily or hourly.

Create your first routine →

Related