Most AI agent success stories skip the part where things don’t work. They focus on the seamless way the AI agent works and how much time is saved. I’ll admit, I’m guilty of that, too.
Focusing exclusively on the success of AI agents does miss what can often be part of the reality: a little bit of trial and error, or what I like to lovingly refer to as ’tech finagling’.
When we omit the part where a user had to problem solve to get their AI agent up and running, users might get frustrated when their AI agent doesn’t work the first time.
In reality, AI agents can take a little troubleshooting to get working well. And while tech finagling won’t sound appealing to some users, I’m here to double down and tell you it’s worth pushing through.
I recently wrote a customer success story about Window Nation, after interviewing their Project Manager, Zita Cajthaml. I hope you’ll hop over and read the full customer story, because Zita has made some big improvements to their creative team’s Wrike instance in the last year — plus, the company’s Wrike usage has grown tremendously in number of users and workflows.
While chatting with Zita, I got to hear how her first AI agent failed, and how she problem-solved her way to AI agent success. It was an inspiring story I wanted to share with more of our users.
The story of her first Wrike AI agent isn’t a straight line from idea to impact. It’s a story about building something, watching it quietly fail, tracking down why, and fixing it. Which, honestly, is the kind of story that’s a lot more useful to other users who are setting out to build their own agent.
When canceled work still counts against your team’s capacity
Window Nation’s creative team assigns work based on capacity. Zita had already built ’effort’ into every task and project blueprint, so the moment a designer or copywriter got assigned to a task, their bandwidth calendar reflected it. If someone was booked for eight hours, the project manager knew they were at capacity.
It worked well, but there was one exception: canceled projects.
When a project got canceled, an existing automation moved it into a canceled folder, but the assignees, due dates, and effort stayed exactly as they were. That meant the bandwidth calendar kept counting hours for work that no longer existed, showing designers and copywriters as fully booked when they actually weren’t. Zita had to go into those individual tasks and manually unassign everyone, every time, just to keep the calendar accurate.
So she decided to build an agent to replace that tedious process.
Why the first version silently failed
Zita built an agent designed to trigger when a project’s status changed to ’canceled’ and then clear the assignees from its tasks. On paper, it should have worked.
Instead, it used up her team’s entire quarterly AI token allocation and accomplished nothing.
The cause turned out to be a subtle timing issue. Her existing automation moved canceled projects into a canceled folder, and by the time that happened, the status had already changed. The agent was watching for the change to ’canceled’, but it was only ever encountering projects that were already canceled by the time it saw them. The trigger condition was technically correct, and it was also functionally invisible.
It’s a common enough issue when it comes to AI agents: the agent wasn’t wrong, it just wasn’t looking for the right kind of signal.
How switching the trigger logic solved it
Working with Wrike’s product team, Zita was able to rework the trigger. Instead of watching for a status change, the agent now watches for state: it checks whether a project sitting in the canceled folder already has canceled status, and if so, clears the assignees.
That one adjustment, from change-detection to state-detection, was all it took.
"We fixed it," Zita said. "It wasn’t that what I put in was wrong, we just needed to switch the phrasing."
From manual cleanup to a problem Zita no longer thinks about
Today, the agent runs quietly in the background. When a project gets canceled, pre-assigned team members are automatically removed from its tasks, no manual cleanup from Zita required.
The impact isn’t just about hours, though Zita estimates she gets back up to two hours on her busiest weeks. It’s about not having to think about it at all.
"It’s an additional step that I don’t have to worry about," she said. "Now I don’t have to go back and remove them from things because the whole project was canceled. It just frees up the additional time it would take to manage the workload."
At Wrike, we have a name for particular time suck: the dark matter of work, the invisible administrative tasks that don’t show up on anyone’s list but quietly drain hours anyway. It’s exactly the kind of work AI agents are suited to absorb.
Up next: teaching agents to track when work really happens
Zita already has her sights set on building her next agent. Right now, when a task is marked complete but its parent project is still in progress, the bandwidth calendar keeps counting the scheduled effort, even for finished tasks. She and her project coordinator currently disable that effort manually.
Her next agent idea involves automatically updating a task’s start date when it’s marked ’in progress’ and its due date when it’s marked ’complete’, so the calendar reflects when work actually happened instead of when it was scheduled to happen.
"I feel like when you start getting to the task level, automations get a little murky," she said. "That’s more of an AI agent thing."
Lessons from AI agent finagling
If your first AI agent doesn’t work the way you expected, you’re in good company. Zita’s experience is a reminder that building AI agents involves a couple steps: writing accurate instructions and ensuring the instructions create your desired result. And while those steps might take a little finagling to get right, they’re worth the time you’ll save in the long run.
Are you ready to start building your own AI agents? Start a free Wrike trial and start cutting out time-consuming manual tasks and leaving them to your AI agents.
