TL;DR: Agents can now reach into Slack channels as well as email inboxes. You can use any of your custom fields to tell an agent which slice of work to look at, and agents can now read and set a task's Importance (High, Normal, Low) based on what they find. Additionally, agents now read the full record behind a Link-to-Database field and can see who has approved a task, plus a handful of behind-the-scenes fixes make Wrike steadier on busier projects.
Featured example: the At-Risk Escalation Agent. When a task's finish date passes, the agent posts an at-risk summary into the project's Slack channel and emails the assignee the same moment.
Hey Community! 👋
Welcome to Wrike Agent News!
This monthly digest features updates, learnings, and how-tos from the Wrike R&D team.
This month's theme is earning your trust on real work. April was about giving agents finish power: starting approvals, sending emails, and kicking off blueprint projects. May is about making sure the agent does exactly what you told it to do on the bigger, busier projects your team actually runs.
Five things shift this month:
- Broader reach: Agents reach further by connecting to Slack alongside email.
- Targeted focus: They see exactly the slice of work you point them at using any custom field and stacked filters.
- Urgency flags: They can now set the Importance field on a task (High, Normal, Low) based on what they read.
- Deeper knowledge: They know more about each piece of work they read, including Link-to-Database records and approver decisions.
- Behind-the-scenes fixes: System updates close real-world gaps in how agents behave on busy projects.
💬 New Action: Agents Can Post to Slack Channels
A risk report flags a slipping project, and the team finds out in their #pmo-risks channel instead of a Wrike comment they need to remember to open. A blueprint kicks off, and the announcement lands in #project-launches. People who live in Slack now hear from the agent in Slack, instead of having to remember to check Wrike.
You connect your Slack workspace once, then pick a single destination channel when you set up the action. That channel is where every message from this action goes. One action maps to one channel. If you need messages to land in different places (risks to #pmo-risks, launches to #project-launches), set up a separate action for each. The agent writes the message based on the work item it is responding to and the instructions you wrote into the action. The message is delivered by the Wrike Slack app and includes a link back to the Wrike work item.
Pro tip: Be specific in your action instruction. "Post the task title, assignee, and due date" works well. "Notify the team" gives the agent too much creative freedom over what it writes.
Why this matters: An agent that flags something but only posts a Wrike comment does not always get heard if the message sits where the wrong people are looking. Slack changes that. Combined with the email action from April, the agent can now reach people in two places: their email inbox or the Slack channel where their team already lives.
Current limitations: No replies into threads and no @-mentioning Slack users yet . Threading and mentions are on our roadmap.
⚡ New Action: Agents Can Set Importance
A rush order arrives with a 48-hour turnaround, a customer comment uses the word "URGENT", or a task is about to miss its SLA. Until this month, agents could spot those signals in the content, but they could not change the Importance field, the native High / Normal / Low marker the rest of the team actually filters on. Teams worked around it with custom priority fields, which split the signal across two places and cluttered dashboards.
This month, agents can read the current Importance value, decide what it should be based on the task content, and set it - High, Normal, or Low, directly on the native field. The activity log records the previous value, the new value, and the reason the agent gave for the change.
Pro tip: Be specific about what counts as High for your team. "Mark as High when the task description contains URGENT, ASAP, or escalation language" is concrete. "Be smart about priority" leaves the agent guessing.
Why this matters: This closes the gap between the agent detecting urgency in the content and flagging it where the team actually watches. If your team already filters or sorts by Importance, the agent now contributes to that signal directly on the native Wrike field rather than requiring a custom-field workaround.
Scope: Native Importance field only (High / Normal / Low). Custom fields used as priority proxies are still updated through the existing Update Custom Fields action.
🔎 Sharper Filtering: Any Custom Field, Any Slice of Work
Most teams organize their work with the custom fields they actually use, such as Region, Client Tier, Priority, Effort, a dropdown for stage, or a checkbox for "needs legal review." This month, you can use any of those fields to tell an agent which slice of work to look at. Write something like "tasks where Region is EMEA" or "tasks where Client Tier is Tier 1 and Effort is more than 8 hours" into your agent's instructions, and the agent will work with only the matching tasks.
You can also stack filters. Narrow a set of projects by status, then ask the agent to find the tasks assigned to a particular person within those projects. The agent reads only the matching tasks inside the matching projects.
Pro tip: Use the custom-field vocabulary your team already uses. It does not matter what kind of field you use (text, dropdown, number, percentage, checkbox); they all work the same way now.
Why this matters: When you tell an agent which slice of work to focus on, Wrike narrows the work down before the agent reads anything. The agent looks at exactly the tasks you asked for. This consistency keeps the agent reliable on real projects, even when a project has hundreds of tasks.
📖 Richer Context: Agents See More of Your Work
Where Sharper Filtering controls which work the agent looks at, Richer Context controls how much the agent knows about each item once it is looking. Two changes this month expand what the agent reads.
Link-to-Database fields reveal the full record
Before this month, when an agent reads a task with a Link-to-Database field pointing at a record - say, a "Customer" field pointing at a Customer database, the agent saw only the name of the linked record, like "Acme Corp." Now the agent sees every column on that record: the CSM, the contract tier, the regional contact email, the renewal date, and whatever fields you have configured on the linked database.
This removes the need to copy columns from a linked database into separate custom fields on the work item just so the agent can read them.
Pro tip: If you have built agents that rely on duplicated fields because the agent could not see the linked record, you can stop duplicating now. Point the prompt at the linked field directly.
Agents see approver decisions
When an agent reads a task that has an approval flow on it, the agent can now see each approver's decision by name, decision, and timestamp (who approved, who rejected, and who has not yet responded).
The top use case for this is reminding only the approvers who have not responded after a couple of days. Before this month, the agent had no way to tell who was still pending. Now it does.
Pro tip: Refer to approvers by their role in the prompt: "Remind any approver whose decision is still pending" and let the agent resolve the names from the approval chain. You do not need to list approver names yourself.
Why this matters: An agent that knows more about each piece of work makes better decisions. The same prompt that used to fall back on just the customer's name now has the customer's CSM email, contract tier, and region to work with. The change is invisible in the UI, but highly visible in the quality of the agent's actions.
🛡️ A Steadier Foundation
A handful of changes improve the experience for teams running agents on active projects:
- Blueprint projects: Agents on blueprint projects now run on every task in the new project. Previously, the agent fired only on the first item in the new project. Now every task created from the blueprint triggers the agent as expected.
- Sub-item scoping: The "all subitems" scope reliably runs on every sub-item when a template folder is copied, ensuring all children run as expected.
- Log filters: The agent log now has filters. Narrow your view by agent, by action, or by time, instead of scrolling through a long list of every run.
- Importance filtering: Agents that filter by Importance no longer fail when there are multiple custom fields sharing a name.
🤖 Agent of the Month: At-Risk Escalation Agent
Every team that runs work to deadlines faces the same problem: a task slips its finish date, nobody notices, and the consequences show up later as a delayed project or a surprised client.
An automation can run when a date passes, but it sends the same pre-written message to the same list every time. It cannot read a specific task, judge how serious a particular slip is, and pick which channel and which person to escalate into. That is the difference between a generic notification and a smart escalation.
The Solution
A three-step agent built on the Date-reaches trigger and this month's new Slack action. When a task's finish date passes, the agent reads the task, posts a focused summary into the project's Slack channel, and emails the assignee directly at the same moment.
How it works
- Trigger: Date reaches → Finish date → Has passed. The agent runs automatically the instant an active task in the project crosses its finish date without being completed.
- Context: The agent reads the task details, including its title, the assignee, relevant custom fields (like the project owner's contact details), recent comments, and the original due date.
- Action 1 (Post to Slack): The agent writes a short at-risk message and posts it into the project's Slack channel with a link back to the work item.
- Action 2 (Send email): The agent emails the assignee directly with a longer version of the summary, detailing what the task is, what slipped, and the expected next step.
The agent log records the run, providing delivery status for both the Slack post and the email. This pattern adapts easily to client-delivery escalation, internal milestone tracking, and contract-deadline reminders.
Click the link below for the complete configuration, prompts, and customization guide.
👉 Solution and configuration
🧩 Combining This Month's Features
Picture a customer success team running an agent on their renewals pipeline. Each task in the pipeline has a Customer field that links to a Customer database containing the columns the CSM team uses to organize their work: CSM owner, contract tier, region, and renewal date. The team wants a daily summary posted into their CSM Slack channel of Tier-1 renewals coming up in the next 30 days.
The Automated Workflow
- Trigger: Scheduled (weekday mornings at 8 AM)
- Scope: Tasks in the renewals folder where the linked Customer's Contract Tier is "Tier 1" and Renewal Date is within the next 30 days.
- The Agent Action: The agent reads each matching task, reads the full Customer record behind the link (CSM's name/email, region, renewal date), and posts a short summary into #cs-renewals. Each renewal is named alongside the responsible CSM, the renewal date, and a link back to the work item.
This utilizes three of this month's new features at once: sharper filtering picks the right tasks, richer context reads the CSM details from the linked customer record without manual data duplication, and the new Slack action puts the result directly in front of the team.
Questions or Feedback?
- Want help setting up any of these features? Reach out to us in the comments.
- Need a different agent type? Contact your Customer Success Manager.
- Found a bug or have feedback? Use the feedback link in the product or let us know in the comments.
On Our Radar
Areas we are actively exploring next:
- Agent log grouped by run: Making it easier to follow one run of an agent from start to finish instead of scrolling through a long chronological list.
- More date conditions to trigger on: Moving beyond "has passed" to add more ways to trigger or filter on date fields, including options like "a week before" or "within the last 7 days."
Your feedback shapes our roadmap. Keep testing, keep sharing what works (and what doesn't).
