TL;DR: This release is all about precision and control. Agents can now move or add tasks to specific folders, adjust start and due dates, and reason across context (parent fields, sibling tasks, cross-folder lookups). They trigger on API changes, support per-action filters and checkbox fields, and can read formula field outputs. Featured example: an “intake deduplication” agent that scans existing work for similar items, flags likely duplicates, and routes only truly new requests, replacing complex rule sets with a single reasoning agent.
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 precision: every new feature is focused on giving you finer control over what agents do, where they operate, and how you track everything that happens.
📍 New Action: Location Change
Agents can now move tasks between folders or add them to additional folders based on content, status, or whatever logic you put in the prompt.
There are two modes:
- Move to location pulls the task out of its current folder and places it exclusively in the target.
- Add to location keeps it where it is and adds it to another folder, which is useful when you want visibility across teams without losing the original context.
When writing the agent’s instructions, you embed location chips (structured references to specific folders or projects) directly in the prompt text. The agent reads the task, reasons about which destination fits, and picks from those chips. You control where things can land; the agent decides which one.
Why this matters: Imagine a setup with more than 15 automation rules just to route tasks to the right folder, each rule covering a single condition. With location change, a single agent can read the task, reason about where it belongs, and move it. One agent replaces the whole rule set because the LLM handles the combinatorial logic that static if‑then rules cannot.
📆 New Action: Start and Due Date Change
Agents can now modify start dates and due dates based on workflow conditions.
Use case: A project kickoff agent can read the project start date, calculate milestone dates based on the project type, and set due dates on key deliverables. Or a simpler pattern: when a task moves to “In Progress,” set the start date to today if it’s empty.
Why this matters: Date management has been one of the most requested agent capabilities, and it is an area where agents add clear value over basic automations. An automation can set a fixed date, but an agent can read the task context and reason about what the right date should be.
🔎 Expanded Context: Parent Fields, Siblings, and Cross-Folder Lookup
Agents just got significantly smarter about what they can see.
Parent item custom fields
Agents acting on a sub-task can now read custom field values from the parent item. Use case: a task inherits its priority from the project it belongs to, so the agent reads the project’s “Client Tier” field and uses it to decide how to handle the sub-task.
Sibling awareness
Agents can now see other sub-tasks under the same parent. This enables duplicate detection (is there already a task like this one?), workload balancing (how many open tasks does this folder have?), and comparative reasoning (is this the only overdue item, or are all of them late?).
Cross-folder lookup
Agents can read items from other folders in the same space, not just the folder they are appointed to. Example: a new project request comes into an intake folder, and the agent scans a “Forecasted Projects” folder to check if a matching project already exists before creating a duplicate.
Together, these upgrades let agents reason about context beyond the individual task they were triggered on, shifting from “react to one item” to “understand the situation.”
🔗 Agents Now Fire on API Changes
Agents now trigger when items are created or modified via the Wrike API. Previously, only UI-driven changes fired triggers.
Why this matters: If you use Wrike Integrate, Zapier, or any custom integration that creates or updates tasks via API, your agents will now pick those changes up automatically.
🏷️ Easier Agent Discovery: Comment Icon
There’s a new icon in the comment editor toolbar for finding and appointing agents. Instead of navigating to the agent management panel, you can discover available agents directly from the comment area of any work item.
This also improves the chat experience: selecting an already appointed agent from the comment bar starts a conversation with it right there in the thread.
🛠️ Action Work Items Filtering
Each action now has its own filter picker, using the same filter experience you know from Wrike’s standard filters. You can filter by item type, status, assignee, custom fields, importance, name, or any combination.
Filters are applied before the LLM runs, so filtered-out items do not consume credits.
This solves cases where a triaging agent on a project folder was acting on every sub-item (projects, milestones, everything). Now you can add a filter for “tasks only” and it ignores the rest. Or get more specific with “tasks in status New, assigned to nobody.” Each action in a multi-action agent can have different filters, so one action targets open tasks while another targets completed ones.
☑️ New Custom Field Type: Checkboxes
Agents now read and write checkbox custom fields.
Example use case: A “Reconciliation Complete” checkbox. Instead of someone manually checking the box after filling in all reporting fields, an agent can read those fields, decide whether the data is complete, and then check it, applying judgment, not just flipping a toggle.
The same pattern works for “Triaged,” “Assets Received,” “NDA Signed,” “Brief Approved,” or any binary state that currently requires someone to look at the task and decide.
🔤 Action Naming
You can now name individual actions inside multi-action agents. Instead of “Action 1,” “Action 2,” and “Action 3” in your activity logs, you’ll see labels like “Set Priority,” “Route to Team,” or “Post Summary.”
Why this matters: It’s a small change that makes a big difference when you’re debugging a five-action agent and trying to figure out which action misfired.
📖 Formula Field Reading
Agents can now read formulas and calculated custom field values during reasoning. If you have a field that computes a risk score, aggregates sub-item progress, or mirrors a native field value, agents can see it and use it in their decisions.
This is read-only (formula fields are computed, not editable), but it lets agents reason about derived metrics without you having to duplicate the data into a regular field.
Pro tip: If there’s a field type that agents can’t read yet, create a formula field that references it. The formula output becomes visible to the agent and works as a bridge for any unsupported field type. Point a formula at it, and the agent sees the value.
Under the Hood 👇
- Hard limits on sub-item processing: When an agent is configured to run on "all sub-items", you now get a warning at appointment time showing how many items will be affected. This prevents accidental action spikes on large folders.
- Improved date handling: The LLM layer now correctly interprets relative dates, date ranges, and timezone-aware scheduling.
Agent of the Month: Intake Deduplication Agent 💯
Teams that receive incoming work requests such as support tickets, project intake forms, or creative briefs deal with duplicates constantly. The same request comes in twice, or a new request describes something that already exists under a different name. Catching these manually requires someone to remember what’s already in the pipeline or to search before acting. Most teams don’t.
Why automations can’t do this: An automation can check exact field matches like “if Client Name equals X, do Y.” But incoming requests rarely use the exact same words. “Acme Corp” might come in as “Acme Corporation,” “ACME,” or “the Acme project from last quarter.” Matching requires reading the description, understanding intent, and judging similarity. That’s LLM territory.
The solution: A two-action agent that uses three of this month’s new features, cross-folder lookup, location change, and action filtering, to scan your existing projects, detect duplicates by meaning (not just keywords), and route new requests automatically.
How it works:
- A new request lands in your intake folder.
- The agent reads the request, then scans a reference folder (for example “Active Projects”) for items with similar names, descriptions, or scope using fuzzy matching, not exact matches.
- Action 1 posts a comment: duplicate found, no match, or uncertain.
- Action 2 routes the request to Active Projects if it’s new, or leaves it in intake for manual review if a duplicate was flagged.
The pattern adapts to any domain: support tickets against known issues, bug reports against existing bugs, RFPs against past proposals. New item arrives → the agent scans a reference folder → judges similarity → then routes or flags.
Click the link below for the complete configuration, prompts, and customization guide.
👉 Solution and configuration
Combining This Month's Features
Location change plus action filtering is a powerful combination. Imagine a project intake folder where new requests land:
- Action 1 (filtered to tasks in status “New” with no assignee): The agent reads the request, classifies the project type, and moves it to the correct team folder using location chips.
- Action 2 (filtered to tasks in status “New”): The agent sets the due date based on the project type and the urgency described in the brief.
- Action 3: The agent posts a summary comment tagging the team lead (list the team leads and their folders in the general instruction, since the agent has no access to user data on its own).
You end up with three named actions, “Route Request,” “Set Timeline,” and “Notify Team,” each with its own filter. The activity log shows exactly which action did what.
Questions?
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're actively exploring:
- Context filtering: Expanding what agents can see beyond the 3-level hierarchy limit.
- Sub-item trigger scope: Agents that trigger on changes to sub-items of a specific parent.
- Approval flow actions: Agents that start approval workflows and manage approvers.
- Sequential action dependencies: Actions where Step B uses the result of Step A.
Your feedback shapes our roadmap. Keep testing, keep sharing what works (and what doesn't).
