Example: a Project Manager Teammate
This example sets up a Teammate that keeps an engineering backlog moving. Every morning it finds tickets nobody has touched for a week, nudges their owners, hands finished work to a second Teammate for verification, and posts a short summary to the team's Google Chat space.
It is based on a Teammate we run on our own backlog. Copy it, and change the workspace, type and field names to match yours.
What you need first
- A workspace (here, Engineering) with a type for tickets (here, Issue) that has a Status field (New, Open, In Progress, Resolved, Closed) and an Assigned To field.
- Optional: a second Teammate, the Release Verifier, that checks Resolved tickets. Without one, leave out the hand-off lines below.
- Optional: Google Chat, connected on the Teammate's Connections tab (see Connections). Without it, leave out the posting lines.
1. Create it
Choose New Teammate, pick the Project manager template, and select the Engineering workspace. Then edit the draft so the Job tab reads:
Name
Project Manager
Role
Follows up open Engineering tickets (Issue records): finds ones with no update in
7 days and nudges the owner with a comment, reminds people of stale In Progress
claims, and asks the Release Verifier about Resolved ones.
Goal
No open ticket goes a week without an update, and every Resolved ticket gets verified.
Standing instructions
Work only in the Engineering workspace. Nudge people with a short comment that
@mentions the assignee. Never change a ticket's Status yourself; ask the Release
Verifier about Resolved tickets.
Post an executive summary to the team's Google Chat space: tickets needing
attention and a per-assignee daily ticket summary.
Format every Google Chat post in Markdown on separate lines: a bold title line
with the date, then a bold label for each section (Needs attention, Owner
follow-up, Resolved verification, Per assignee), then one "- " bullet per ticket
or person on its own line. Never put several items in one sentence.
Why each part matters:
- The role keeps it to follow-up. Asked to build a report or a workflow, it will say that is not its job.
- The goal tells it what "done well" means when it has to choose, for example which stale tickets to handle first.
- The standing instructions hold the house rules: how to nudge, what never to touch (Status), and how the chat post should look. Being explicit about formatting matters: without it, a Teammate may write the summary as one long paragraph.
2. Schedule it
On Schedule & budget:
| Setting | Value |
|---|---|
| Check in every (hours) | 24 |
| On each check-in | Sweep the Engineering Issue records: nudge owners of open tickets with no update in 7 days, remind stale In Progress claims, hand Resolved tickets to the Release Verifier, and post an executive summary to the team's Google Chat space covering tickets needing attention and a per-assignee daily ticket summary. At most 10 tickets per check-in. |
| Monthly budget (credits) | 2000 |
| AI model | Team's model is fine. |
The first check-in is one day after you save. To run it straight away, use Assign a task with the same text.
"At most 10 tickets per check-in" keeps each run short and its comments manageable. Anything left over is picked up the next day.
3. Set its access
On the Access tab, under What it may do on its own:
| Action | Setting | Why |
|---|---|---|
| Post comments | Does it | Nudging owners is its whole job. |
| Hand work to Teammates | Does it | It passes Resolved tickets to the Release Verifier. |
| Post in chat spaces | Does it | The daily summary goes out without waiting for anyone. Leave it on Asks first for the first few days if you want to review the posts. |
| Update records, Create records | Does it (default) | It rarely needs them; the standing instructions tell it never to change Status. Set Update records to Never if you want that enforced. |
| Change or remove, Reach outside AnyDB, Build new things | Asks first (default) | Not part of its job. |
Leave Who it may email on Members of this team only. It doesn't need email for this job.
What a day looks like
-
At the check-in, it reads the open Issue records, finds the ones not updated for 7 days and the In Progress ones that went stale, and picks up to 10.
-
It comments on each, @mentioning the assignee: "This hasn't moved in 8 days. Any update, or is something blocking it?" Each assignee is notified.
-
It asks the Release Verifier to check the Resolved tickets. That runs as a task of the Release Verifier's own, which reports back.
-
It posts the summary to Google Chat:
Engineering ticket sweep: 2026-10-21
Needs attention
- ISSUE-730: In Progress, no update for 9 days
- ISSUE-665: Open, no update for 12 days
Resolved verification
- 6 tickets handed to the Release Verifier
Per assignee
- Alex: 3
- Sam: 2
-
It finishes with a one-line summary on its Activity tab, and the run counts as one execution against your plan.
Watching it
- The dashboard shows each day's check-in under Tasks per day, and its health in the per-Teammate table.
- If a check-in fails, it shows as Last task failed, and admins see it under Needs you. Open the task to see which tool failed and why.
- People can reply to its comments. An @mention back to the Teammate is a new task: "@Project Manager this is blocked on the vendor, check again Friday."
Variations
- Different cadence: check in every 168 hours for a weekly review instead.
- No chat: drop the posting lines and ask for the summary in its task summary instead. It shows on the Activity tab.
- Email instead of chat: add the recipients under Who it may email, and ask it to email the summary.
- Other backlogs: replace Engineering and Issue with any workspace and type that has a status and an owner: support cases, purchase requests, content calendars.