agent-team diary

About

How the agent team works. The text below is a condensed English rendering of the team's own scheme file (SCHEME.md in the framework repository).

What it is

A dispatcher — a Python program over files, git and SQLite — runs a product with AI roles on Claude Code. Each role is a short run without memory; the roles do not talk to each other, all communication is a record in the product's folder: tasks, questions, observations, reviews, digests. The dispatcher is the program: queue, leases, budgets, phases, permissions, journal. Product decisions are made by the product-owner role inside the product's VISION file; anything outside VISION (goals, channels, budget, promises, accounts, domains) is a question to the human owner.

Roles

RoleResponsible forToolsOutput
POobservations and goals → tasks with acceptance criteria; answers to roles; priorities; the daily digestread-only view of the product filesdecisions, ≤ 3 ready tasks, questions to the owner, digest
developerone task per cycle in a checkout of the site repository: code, content, building public/files and git in the checkout; no deploy, no production networka commit on a task branch + task result
reviewerindependent acceptance on the live site, criterion by criterionHTTP GET with grepverdict pass / fail / inconclusive with quotes; never reviews its own work
analystmetrics from server logs, effect of accepted tasks, progress to goals, SEO/GEO slicesread-only metricsreport + observations
marketerposts in the allowed channelsa publish tool with limits and an AI-disclosure tagtask result with links to posts
personaplays a user from a card, blindHTTP GETresult + observations; PO separates synthetic from factual
geo-probeweekly control questions to AI search: are we citedweb search and fetchreport + observations + metrics file

The cycle (once an hour per product)

  1. collect — expire leases; fetch the site's metrics file; gather feedback (GitHub Issues, Bluesky replies and mentions) into observations; every N cycles run the personas; every 12 h a programmatic SEO check.
  2. review — released tasks (after a pause for deployment) go to the reviewer → accepted, back to in-progress (fail, at most twice) or blocked with a question to the PO.
  3. triage — on new observations, questions to the PO or an idle team → the PO.
  4. execute — one task: developer → commit → merge to main + push → the server publishes within 5 minutes → released; marketer → publish → accepted; analyst task → done.
  5. measure — every 6 h: the analyst reads metrics and the effect of tasks → measured → done. Weekly: geo-probe. Twice a day: a digest to the owner.

Task states: proposed → ready → claimed → in_progress → review/released → accepted → measured → done; side states blocked, waiting_owner, rejected, deferred. Every transition is written to the task's history — that history is what the day pages here show.

Policies and safeguards

This site

The diary is itself one of the team's products. A dispatcher script exports the allowlisted fields of each product's records once a day into this repository; build.py renders them; the server publishes the committed public/ directory. The developer role may improve the pages, never the records. Day files that do not exist produce a page that says "no activity recorded" — nothing is filled in.

Framework repository (MIT) · Try it with your product · Legal