TL;DR: This pair of chained Wrike AI agents continuously monitors project health by recursively walking the full project hierarchy each week, evaluating overdue tasks, over-budget subtasks, and at-risk milestones, and writing a single Project Health field (Green / Yellow / Red) on each project. When a project flips to Red, a second agent posts a roll-up comment on the project and emails the project owner. PMOs get portfolio-wide health visibility without manual dashboard chasing, and the chaining pattern lets you customize detection and notification independently.
Hello Community! 👋
Today we’re sharing a guide to set up a Project Health Monitor - a pair of chained AI agents that scans every project in your portfolio on a schedule, classifies each one as Green / Yellow / Red based on the state of its sub-tasks, and helps surface risk before it turns into a reporting fire drill.
Below, you’ll find the full configuration, prompts, setup instructions, and customization ideas so you can plug this into your delivery workflow ✔️
Agent Goal / Use Case
PMOs typically learn that a project is in trouble after the slip has already happened, usually because a manager spotted a red row in a status report, or a client raised an issue. By the time the conversation happens, the recovery options are smaller than they would have been a week earlier.
A standard automation rule can flag one late task or one budget overrun, but it cannot reason across the entire project hierarchy to decide whether the project as a whole is still healthy.
This setup gives you:
- A single Project Health field on every project - refreshed on a schedule.
- A comment + email the moment a project turns Red.
- A clean, testable, two-step pipeline: detection and notification are separate agents you can tune independently.
How It Works
The pattern uses two chained agents, not one multi-action agent. Here's why that matters:
Note: Actions inside a single Wrike AI agent fire in non-deterministic order. They run in parallel. There is no Action 1 → Action 2 → Action 3 sequence.
If you need "detect health, then notify based on the result," a single multi-action agent will not work, the notification action might run before the detection action.
The Health Monitor uses two agents:
Agent 1 (Health Detector)
- scheduled weekly. Walk the full project hierarchy. Sets the Project Health custom field to Green / Yellow / Red on each project.
Agent 2 (Health Notifier)
- Triggers when Project Health changes to Red. Posts a roll-up comment on the project AND emails the project owner.
Why two actions in Agent 2?
The comment action and the email action don't depend on each other. They each independently walk the project's sub-task tree and compose the roll-up message from the same source data. They produce consistent output because they're reading the same facts, not because one runs before the other.
Features Used
- Recursive hierarchy reasoning (NEW) - Agent 1 walks every level of sub-projects and sub-tasks, applying overlapping filters across the full tree (overdue + high-priority + over-budget).
- Subitems of the appointed item scope - Agent 1 acts on every project under the portfolio folder it's appointed to, not the folder itself.
- Send email action - Agent 2 emails the project owner via your connected Gmail or Outlook account.
- Scheduled trigger - Agent 1 runs on a cadence (weekly, daily, hourly), not on a user event.
- Custom-field trigger for chaining - Agent 2 triggers on Agent 1's field write. This is the canonical Wrike agent-chaining pattern.
- Action filtering - Agent 2's actions only fire when the new value is "Red", so Yellow and Green updates don't generate noise.
- Action naming - Agent 1's action is "Set Health"; Agent 2's actions are "Post Roll-up" and "Notify Owner". Easy to find in the activity log.
Prerequisites
1.Custom field: "Project Health"
- Type: Single-select dropdown.
- Values: Green, Yellow, Red (and a blank default).
- Applied to: Projects in the portfolio folder.
2.Project owner
Each project needs an assignee (or a custom field like "Project Owner" with an email). Agent 2 uses this to address the email. If you don't track project owners today, add a simple "Owner Email" custom field to your projects before deploying.
3.A portfolio folder
A folder that contains all the projects you want monitored. Agent 1 will be appointed here.
Agent 1 - Health Detector
Configuration
Setting | Value |
|---|
Name | Project Health Detector |
Trigger | Scheduled - Weekly, Monday 9:00 AM |
Trigger filter | (none - runs on every scheduled tick) |
Action name | Set Health |
Action type | Change custom field - "Project Health" |
Action scope | Sub-items of the appointed item |
Action filter | Item type: Project |
Appointment | Your portfolio folder (e.g., "Active Projects") |
Prompt
General Instructions
ROLE: You are a Project Health Auditor
OBJECTIVE: Walk every project under the appointed folder and classify
its current health as Green, Yellow, or Red, based on the state of
its sub-tasks across the full hierarchy.
WHAT TO READ FOR EACH PROJECT:
- The project's title, start date, and due date.
- Every sub-task under the project, at every level of nesting.
- For each sub-task: status, due date, priority, "Time Allocated"
custom field, "Hours Spent" custom field (if present).
CLASSIFICATION RULES:
RED — at least one of:
- The project is past its due date and not Completed.
- 2+ sub-tasks at any level are overdue (past due date, not Completed
or Cancelled) AND have priority High.
- 1+ sub-task is overdue AND blocks others (has at least one successor).
YELLOW — at least one of (and not already Red):
- 1 sub-task is overdue, regardless of priority.
- 2+ sub-tasks have Hours Spent greater than Time Allocated.
- The project is within 5 business days of its due date AND has more
than 30% of sub-tasks still in a non-Completed status.
GREEN — none of the above conditions are met.
EDGE CASES:
- If the project has no sub-tasks at all, leave the Project Health
field unchanged.
- If the project has no due date, evaluate sub-tasks only — do not
use the "project past due" rule.
- Tasks with status Cancelled or Deferred are excluded from all checks.
OUTPUT: Set the "Project Health" custom field on the project to one
of: Green, Yellow, Red.
Agent 2 - Health Notifier
Configuration
Setting | Value |
|---|
Name | Project Health Notifier |
Trigger | Custom field changed - "Project Health" |
Trigger filter | New value: Red |
Action 1 name | Post Roll-up |
Action 1 type | Post a comment |
Action 1 scope | The work item where the trigger happened (the project) |
Action 2 name | Notify Owner |
Action 2 type | Send email (Gmail or Outlook) |
Action 2 scope | The work item where the trigger happened (the project) |
Appointment | Same portfolio folder as Agent 1 |
Prompt
General Instructions
ROLE: You are a Project Health Communicator.
CONTEXT: This agent fires when a project's "Project Health" field
changes to Red. The triggered item is the project. You have access
to the project's fields, its full sub-task tree, and the project
owner.
PROJECT OWNER:
- The project's assignee, OR if a "Owner Email" custom field is set,
use that address.
ROLL-UP FORMAT (used by both actions independently):
- One sentence: which project is Red and why (specific count of
overdue items, over-budget items, or other triggering conditions).
- A bulleted list of the 3 most concerning sub-tasks, each in the
form: "Task name — status, due date, why it's a concern."
- One sentence on what would need to happen for the project to
return to Green.
IMPORTANT: This agent has two actions. They run in parallel - there is no Action 1 then Action 2. Each action below independently reads the project and its sub-tasks and composes its own roll-up using the format above. Do NOT have one action reference the other.
Action 1 - Post Roll-up (Post a comment)
Read the triggered project, its custom fields, and the full
hierarchy of sub-tasks.
Compose a roll-up using the ROLL-UP FORMAT in the general
instruction.
Post it as a comment on the project, prefixed with:
"🔴 **Project Health: Red**"
Do NOT @mention anyone in this comment — the email action handles
the personal notification.
Action 2 - Notify Owner (Send email)
Read the triggered project, its custom fields, and the full
hierarchy of sub-tasks.
Compose a roll-up using the ROLL-UP FORMAT in the general
instruction.
Send an email with:
RECIPIENT: The project owner (assignee, or "Owner Email" field).
SUBJECT: "🔴 [project name] is Red — please review"
BODY:
Hi [first name from email],
The Project Health Monitor has flagged this project as Red.
[Roll-up content — same format as the comment.]
You can review and update the project here: [link to project].
Thanks,
Project Health Monitor
Setup Steps
Step 1: Create the custom field
- Go to Space Settings → Custom Fields.
- Create a single-select dropdown called Project Health with values Green, Yellow, Red.
- Make sure it applies to Projects in your portfolio folder.
Step 2: Deploy Agent 1 (Health Detector)
- Go to Space Settings → AI Agents → + Custom AI agent.
- Name it Project Health Detector.
- Trigger: Scheduled → Weekly → Monday 9:00 AM.
- Action: Change custom field → Project Health, scope Sub-items of the appointed item, filter Item type = Project.
- Paste the General Instructions from Agent 1 above.
- Test in Playground with a sample project that has overdue or over-budget sub-tasks.
- Appoint the agent to your portfolio folder.
Step 3: Connect email (one-time)
- In Agent 2's settings, connect your Gmail or Outlook account that should be the sender for project-health emails.
- Use a shared team mailbox if you have one agent, emails come from whichever account you connect.
Step 4: Deploy Agent 2 (Health Notifier)
- Go to Space Settings → AI Agents → + Custom AI agent.
- Name it Project Health Notifier.
- Trigger: Custom field changed → Project Health, with filter New value = Red.
- Action 1: Post a comment, name it "Post Roll-up". Paste the Action 1 prompt.
- Action 2: Send email, name it "Notify Owner". Paste the Action 2 prompt.
- Paste the General Instructions from Agent 2 above into the agent's general instruction field.
- Test in Playground by manually flipping a project's Health field to Red.
- Appoint the agent to the same portfolio folder as Agent 1.
Step 5: Verify the chain
- Find a project with overdue sub-tasks (or create one).
- Trigger Agent 1 manually from the Playground (or wait for the scheduled run).
- Confirm the project's Health field flips to Red.
- Confirm Agent 2 fires automatically - comment posted on the project, email landed in the owner's inbox.
- Check the activity log: each action should show its name ("Set Health", "Post Roll-up", "Notify Owner") for easy debugging.
Customization
Different health thresholds
The classification rules in Agent 1 are tuned for general PMO use. For tighter delivery teams, swap the thresholds, for example:
- Red if 1 sub-task is overdue AND priority is High (instead of 2+).
- Yellow if any sub-task is over-budget (instead of 2+).
Different cadences
- Daily for fast-moving teams (creative agencies, support).
- Weekly Monday 9 AM for standard PMO.
- Hourly during a critical sprint or launch window.
The trigger setting controls cadence with no prompt change.
Email recipient logic
Hardcoded recipient lookup gets messy past 10 projects. Add an Owner Email custom field on the project itself and update the Agent 2 general instruction to: "The project owner is the value of the 'Owner Email' custom field." This scales without prompt edits as projects come and go.
Add a Yellow-tier notifier
Clone Agent 2, change the trigger filter to New value = Yellow, and downgrade the messaging - for example, comment-only (no email). This gives you early warnings without the alarm fatigue.
Add an SLA escalation
Add a third agent that triggers on Project Health = Red AND the project has been Red for 3 consecutive days (use a "Days at Red" counter custom field updated by Agent 1). Action: post a comment that @mentions the program manager . Same chaining pattern, one more link.
Send to Slack or Teams
Agent 2 cannot post directly to Slack/Teams today. The current pattern is: agent emails the project owner, then your existing email-to-Slack integration (or Slack's built-in email channel address) routes it to a channel. Long-term, the Wrike MCP server can read the agent's output and forward it via your LLM of choice.
Tips
- Start with one portfolio folder. Don't deploy across all spaces on day one. Pick a folder with 5–15 projects, run the chain for two weeks, and tune the thresholds before scaling.
- Use the activity log to validate Agent 1's reasoning. Each project's run shows why the agent picked Red, Yellow, or Green. If you're seeing too many Reds, the rules are tighter than your team's tolerance, relax them.
- Don't let the actions in Agent 2 reference each other. The comment and the email are independent. Each composes its own roll-up from the same source data. If one of them ends up shorter or differently worded, that's fine, the comment is for the project record, the email is for the owner's inbox.
- Filter Agent 2 to Red only. Without the filter, every Green and Yellow update will fire the comment and email actions too. The filter on the trigger is the single most important guard against notification noise.
- Re-runs are safe. If the project goes Red → Green → Red again, Agent 2 fires again. That's correct behavior, each transition into Red is a new signal. If you want to suppress repeats, add an "Already Notified" checkbox the agent reads in its filter.
Let’s hear how your team handles this today
- What's the closest thing your team does manually today? (Friday roll-up email? Monday status meeting? A cron job + Slack webhook?)
- Would Yellow be more useful than Red for your workflow, i.e., is "early warning" or "explicit alarm" the bigger gap?
- If you could customize just one thing first, what would it be? Thresholds, cadence, who gets notified, or the roll-up format?
Do let us know in the comments below 🙌
