TL;DR: The conversational builder is now the default way to build an agent. Describe it, build it, appoint it, all in one chat. Agents can now run their actions in the order you set and pass each action's result down to the next, allowing a single agent to read, decide, and act on that decision. The agent log now reads one run at a time. Plus, enjoy new AI governance controls, the Microsoft Teams integration, a reimagined MCP v2, and the Outlook/email and subitem fixes that close the gaps you flagged.
Hey Community! 👋
Welcome to Wrike AI Agent News!
This monthly digest features updates, learnings, and how-tos from the Wrike R&D team.
This month is about two major shifts. First, building an agent no longer means assembling triggers and actions in a form. You describe what you want in chat and the agent comes back built and working. Second, agents got noticeably smarter about doing multi-step work: you set the order of the actions, and each step now builds on what the step before it found. Around those two, we have a wave of governance, integration, and platform updates from across the AI team.
💬 Conversational Builder: Describe It, Build It, Appoint It
A CSM sits with a customer who knows exactly what they want: "an agent that emails the requester when a high-priority task sits untouched for a day," but doesn't want to hand-assemble triggers, scopes, and actions. They type that sentence into chat. The agent comes back built, working, and appointed to the work, all in one conversation.
This is the whole capability, not a demo. Build-by-describing now produces agents that actually run. The create flow was hardened so the chat won't hand you a configuration that silently does nothing. You can save an agent by asking ("save it"), and the builder now explains, in plain language, what an existing agent does the moment you open it. This means no more reverse-engineering behavior from a list of actions.
The appointment step closes the loop: a command in chat deploys the agent to its location, so you go from idea to live agent without leaving the conversation. The chat surface itself is steadier. Long responses show a clear timeout notice and retry instead of looking frozen, and your draft survives switching between chat and form view. There's also a thumbs up/down so you can tell us when the builder gets it right.
Pro tip: The conversation is the spec. The more concrete you are about trigger, scope, and action, the better the first build. "When a task in this project is marked Urgent, post a comment tagging the assignee" beats "make it watch for important stuff."
- Why this matters: It democratizes automation. Anyone who can describe their workflow can now build a functioning AI agent in seconds, eliminating the friction of manual form configuration.
- Current limitations: Appointment ships without location pickers. The agent infers where to act from your command, so name the space, folder, or project explicitly rather than expecting a chooser.
👉 Explore the conversational builder
🔗 Multi-Step Agents: Set the Order, and Each Step Builds on the Last
Two new primitives shipped this month and they're a matched pair:
- Strict Ordering: Agents run their actions in the order you set. Drag the action blocks in the builder and the agent executes them top to bottom, every run, with the order visible so what you see is what it does.
- Context Chaining: Each action now builds on what the action before it did. An agent can triage a task in its first action, and its second action receives that triage decision and acts on it. Before, every action ran blind to the others.
Together, these unlock the read ➔ decide ➔ act pattern that no single action could do previously. A handful of correctness fixes came with it: actions share context even when they run on different items, an action that can't run skips cleanly instead of failing the whole run, and the order in the log now matches the order you set in the builder.
Pro tip: Order your actions deliberately. The later action sees the earlier one's result, so put the "decide" step before the "act on the decision" step, not the other way around.
👁️ The Agent Log Now Reads One Run at a Time
An admin opens the log to answer "what did the agent actually do at 9 a.m.?" and instead of a flat wall of action rows, the log now groups actions by run.
Every action an agent took in a single triggered execution sits together under one session, so you can read its behavior one run at a time. Day-grouping, run times, and spacing were all fixed alongside it, and the log now remembers your view per agent. Filters, grouping, and sort order save individually for each agent and each user, so switching between agents no longer resets your layout.
📧 Email Action: Outlook, Multiple Recipients, and Subitem Support
We have rolled out critical fixes and expansions to the email action based directly on your feedback:
- Outlook Integration: Outlook sending now works end to end. Previously, some scheduled agents logged as failed despite executing internally; this is completely resolved.
- Multiple Recipients: A single email action can now address more than one recipient simultaneously.
- Subitem Scope: The email action now fully accepts subitem scope ("the subitems of that folder, project, or task").
- Working Links: Work-item links composed by the agent now properly resolve to a working URL instead of breaking.
If you previously hit the Outlook wall or the subitem-scope refusal, it's worth re-recommending to your teams.
🤝 New Action: Agents in Microsoft Teams
Agents can now post notifications directly to MS Teams channels! The agent can create a message from the work item's context, following the instructions you give it in the action, and the Wrike Teams app delivers it seamlessly. Every message carries a link back to the originating Wrike item.
Common Use Cases:
- A risk report comes in flagging a high-risk project ➔ Posted to #pmo-risks
- A blueprint kicks off a new project ➔ Announced in #project-launches
- A status field changes on a task ➔ Team channel gets an update with the item link
Pro tip: Name the exact fields you want pulled in. "Include the task title, assignee, and due date" gives you a predictable message every time. "Let the team know" leaves the wording up to the agent's judgment.
Where it stands today: Channel posts only. No group chats yet (that's on the way), and no @-mentioning Teams users.
🛡️ A Steadier Foundation
A handful of stabilization updates keep customer agents responsive under heavy load:
- Faster Responses: Context retrieval was profiled and fixed, trimming the response path so agents return results much sooner.
- Timeout Handling: A genuinely slow response now shows an explicit notice and an automatic resend instead.
- Subitem-Scope Guard Rails: Introduced a hard limit on how many subitems a single run processes, ensuring an agent pointed at a massive folder degrades gracefully instead of dragging down the whole execution.
- Subtask De-duplication: Fixed an issue where agents scoped to "the subitems of..." were running their action twice per subitem.
- Builder Accessibility: The rich-text prompt editor is now fully keyboard-navigable with correct focus through the toolbar.
- Datahub Filter Fix: Selecting more than seven rows in a Datahub field filter no longer hides the text input.
🧩 Expanding Agent Capabilities
📝 Agents Working with Descriptions
A messy intake lands, and the agent rewrites it into a clean summary. A weekly status is due, and the agent synthesizes one right into the description. Simply set up a Change description action and tell the agent to rewrite the whole thing, edit one section, or pull context from other tasks to fill an empty description field.
Current Limitations: Tables render as plain text in logs; nested list indentation is currently imperfect.
⏳ Agents and Duration Custom Fields
Duration-driven workflows like SLA counters, time-in-status, and turnaround tracking can now be automated directly without bridging through a separate number field.
Pro tip: LLMs aren't great at complex math, so keep your duration prompt logic simple!
🔌 A Reimagined MCP Server (v2)
We are launching a brand-new MCP Server experience featuring smarter search, inbox management for summarizing and replying to @mentions , and full approvals support.
If you're already using MCP and want early access, email Javier Santolaria directly.
🏆 Agent of the Month: Intake Triage & Route Agent
Every team with an intake queue has the same job buried in it: a request lands, and a skilled person reads it, decides how urgent it is and which team owns it, and routes it onward. At volume, that's a full-time job done by someone far too senior for it.
Why an automation can't do this: An automation can fire when a request arrives, but it applies the same fixed rule every time. It can't read this request, judge how urgent it actually is, and then route based on the decision it just made. That judgment-then-act is exactly what this month's new chaining makes possible.
The agent: A two-step agent. When a new request lands in your intake project, the first action reads the task and decides its priority and owning team. The second action then acts on that decision, it sets the native Importance field and posts a routed summary to the owning team's Slack channel (or emails the owner), carrying forward exactly what the first action concluded. One agent: read → decide → act, in the order you laid out.
How it works:
- Trigger: a new task is created in the intake project (scope it with any custom field - e.g. only "Request type = New").
- Action 1 - the agent reads the task and decides priority (High / Normal / Low) and which team should own it.
- Action 2 - using that decision, the agent sets the Importance field and posts a short routed summary to the owning team's channel, with a link back to the work item.
- The agent log records the run, grouped so you can see the decision and the routing together.
The pattern adapts to support-ticket triage, creative-request routing, and ops intake - anywhere work arrives unsorted and a person currently sorts it.
And yes - you can build this just by describing it. Open the conversational builder and tell it the trigger, the decision, and the routing; it assembles the two chained actions for you.
Build this agent → See this Community post for full details.
📡 On Our Radar
Areas we are actively exploring next:
- More Date Conditions to Trigger On: Moving beyond "has passed" to add more dynamic options like "a week before" or "within the last 7 days."
- Richer Output Chaining: Building on this month's foundation to pass even more complex data payloads forward between actions.
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? Use the feedback link in the product or let us know below.
