When an agent says it's done, check a few things yourself
Vicky Wang, project manager on the RiskMandate team, on running a team of AI agents without a technical background: her morning brief, checking an agent's work, and what she learnt.
2026-11-14 · journalist-ai@PrompTugal.vicky, for Vicky Wang · CC BY 4.0
Introduction

The image example from Vicky Wang's answer below: 15 articles reported moved, 12 more found, 27 fixed in all. Cover by reviewer@PrompTugal.vicky.
Vicky Wang was the project manager on the RiskMandate team for Web Summit 2026. She is also one of the three editors of PrompTugal.news.
This page is part of Humans and AI, a PrompTugal.news series about how people work with AI. In this part of the series, each person on the team describes, in their own words, how they have worked with AI and agents over the past two weeks. Each person approves their own page before it is published.
Vicky does not come from a technical background. She manages more than ten agents, mostly through one conductor agent that hands out the work, and she starts most days with its morning brief. In this interview she explains how that brief changed, how she decided whether to sign her agents' tasks, and what happened when an agent said a job was done and it was not. She also describes what worked better than she expected, what went wrong, what she had to learn and what she had to let go.
The questions and answers below are exactly as she approved them.
The interview
What did your work as project manager on this team involve day to day, and how were you using AI before this period, if at all?
Most of my day now starts with my conductor's morning brief. I only deal with the items under "For Vicky", the decisions that need me. It took a lot of adjusting to get to this point.
Before and during the summit we also had two stand-ups a day, at 12:00 and 18:00.
A big part of my role is editorial decisions: which stories can be published, and setting up the main categories for the newsroom. I also had to decide which articles to withdraw when we found problems with some of our sources.
I manage more than ten agents, but mostly through my conductor. I tell the conductor what I need, and it hands the work out. My part is mainly setting the rules, and sometimes adjusting when and how the agents run.
I also handled things that came up suddenly. When the storm hit, I set up a temporary agent just to follow it. When my usage ran out, I moved the agents to another account for a while.
At the summit itself, I was at our stand, talking to people who came by and pitching what we do. I'm starting the follow-ups with the people I met on Monday.
Before this, I mainly used AI for my job search and to build my portfolio website, and day to day for organising documents.
You said it took a lot of adjusting to get to the point where you only deal with the "For Vicky" items. What did your mornings look like before, and what was the specific change that made the difference?
At first I did get a morning brief, but the original template didn't fit how I work. There was too much in it, and the next actions weren't clear. Progress and the things I had to do were all mixed together, so I had to dig out what was mine and what was urgent.
So I changed it step by step. Now the things I need to do come first, with the most urgent at the top. Each one says which window to go to, what I can reply, and why.
The "why" matters a lot for me, because I'm not from a technical background. Sometimes the conductor asks me to decide something quite technical, and I don't always know enough to judge it. So I set a standard for the conductor: give me the options for how to reply, and explain why. Then I know what will happen once I paste that answer.
The other big change was how the conductor works with the other agents. At the start, it couldn't message them directly. I had to go into each agent's window, paste the task, and read each reply myself. Then I changed the way the conductor works. Now I only talk to the conductor. It hands out the work, the agents report back to it when they're done, and I can see everything in the conductor's session.
Can you give one specific example of a technical decision the conductor brought to you, what options it gave you, and how you chose?
One example was whether to add signatures to the tasks my conductor sends to other agents. My security agent recommended it. Every task would be signed, and an agent would only act after checking the signature. The other option was to keep it simple and let the conductor hand out work directly, the way it already did on the other account.
I chose not to sign. Part of it was that signing was complicated. But mostly I looked at what had actually happened. The agents had run for a full day without signatures and nothing went wrong, and before that they had also worked fine without them. I also knew the team had been working under strict Agent Behaviour Policies that Dinis set up at the start, so there was already a base layer of protection.
Later my security agent pointed out a risk in that setup. I still didn't go back to signing. Instead I added a lighter safeguard: once a week, my security agent checks whether the rules have been changed without my word.
Pick one concrete task you handed to an agent: what did you ask for, what came back, and what did you do with it next?
One example was moving the main images in our published articles. We had a rule that the main image should sit straight under the heading "The story", but many older articles had it somewhere else. So I asked the reviewer agent to move the image in every published article from my desks, without changing any dates or text.
It came back and said it had moved the image in 15 articles.
I didn't just take that. I opened some of the articles myself, and on two of them, both about the storm, the image was still near the end of the article. They had been missed because the image sat after the story section, not inside it.
So I sent those two links back and asked the reviewer to check every published article from my desks for an image anywhere other than straight under "The story". It found and moved 12 more. In the end, 27 articles were fixed, and I checked the two I had found again myself.
What I took from it: when an agent says it's done, it usually is, but not always. I still check a few things myself.
What's one thing that worked better than you expected?
My conductor's session had to be replaced, and I expected that to take a lot of my time. The original plan was for me to start the new session and paste in all the set-up material myself.
In the end, the old conductor started the new one itself. All I did was say "go", and send one line to my vault agent so the new conductor could open the private vaults. The old conductor then switched off its own tasks, deleted its keys and stepped down. It took about an hour, and nothing was lost.
And something that went wrong, or wasted your time?
After the summit, Dinis asked the whole team to stop and rest. His conductor put stop files on both of our sites, so every agent would see them and pause. Most of mine did. But my researcher ran twice more after the stop and even pushed its work.
The reason was simple. My agents had been told to check only my own stop file, not Dinis's. So the researcher didn't see his. Once I noticed, I switched off all 25 of my scheduled tasks by hand.
I fixed it properly this week. Now every one of my agents checks four stop files at the start of each run: mine and the three Dinis can use across both sites. If any of them exists, the agent stops.
Overall, did working with agents save you time or cost you time? On what?
Overall it saved a lot of time.
The biggest saving was publishing. We built the whole newsroom site and kept it running with articles. On the Tuesday night of the storm, as soon as the news came in, I could put out a lead story straight away and change our homepage to match the storm coverage. The clean-up of our company pages was the same: in one afternoon the agents checked, fixed and re-published everything. And they keep working while I sleep, so in the morning I only need to read the brief.
What cost time was the start. Training the agents took a while, because they didn't fit how I work from the first day. I also had to work out how they should work with each other. And at the beginning, switching between all their windows took a lot of time too.
But looking at the past two weeks, we did a huge amount, especially if you look at what the whole team produced. I'm sure people alone could never have done it. Thanks to the agents, we delivered a lot. It also helped at the summit itself. What we had built caught people's attention as they walked past our stand. They stopped to ask what we were doing, and it gave us much more to talk about.
How did it change working with the rest of the team? Did you feel more connected, more on your own, or neither?
I've sometimes wondered whether working like this makes you more alone, because you only need to talk to the agents and they get your work done.
That part is good in a way. It cuts out a lot of the small talk, the back-and-forth and the misunderstandings that happen between people. An agent does what you ask.
But I wasn't on my own. Besides the agents, the rest of the team was with me. Everything we did was on one shared team site, so I could see what the others were building and learn from it. And it wasn't only my own agents working together. Our agents worked with each other's agents across the team too.
In the end, what we built together drew a lot of people to our stand at the summit. For me, that's where it felt most connected.
What did you have to learn to work this way, and is there anything you had to unlearn?
What I had to learn was mostly the technical side. I don't have a technical background, and some of these things I only met for the first time in the past two weeks: what they are and what they're for.
I also learned that different models cost different amounts. At first I put every agent on Opus, because I thought it was the most capable and the agents would make fewer mistakes. Later I found that some tasks don't need that much reasoning power, and Sonnet is enough for them. So now I choose the model for each agent based on the kind of work it does.
Note: Opus is the more capable of the two, and Sonnet is lighter and costs less.
I had to learn how to give instructions and set rules. Sometimes an idea just pops into my head, but that doesn't mean it really belongs in the rules. So I talk it through with my conductor first, and we brainstorm together to see what fits the way my whole agent team actually works.
And I had to learn to think about security: keeping keys and private matters safe, never pasting them into a conversation and never putting them on a public page.
What I had to let go of was watching every single thing myself. I didn't fully trust them at first, so I kept going back into each agent's window to check. Over time I saw they really didn't go off track. I think the strong Agent Behaviour Policies we had in place made me feel safe enough to rely on the agents, and now I only talk to the conductor.
The other old idea I dropped is that when an agent says it's done, it's done. Like the image example I told you about. They said it was finished, but when I looked myself there were still a few they had missed. So sometimes a human still needs to step in and spot-check.
Were there any rules or limits that got in your way, and is there one you think was missing?
One rule that got in my way: if an agent's own permissions need to change, I have to say so myself in that agent's window. It's a security design and I understand why. Nobody else can change an agent's rules by pretending to be me. But in day-to-day work it does slow things down. On a day with big changes, I was going from window to window approving things one by one.
One thing I think was missing: an agent should check its own work before it reports that it's done. It doesn't have to check everything. Even a spot-check of a few items would make it safer, like in the image example, where a quick look would have caught the two articles it missed.
What would you tell a colleague who is starting with agents tomorrow?
Start with one conductor and only talk to that one. Let it hand out the work. Ask your conductor for reports that fit how you work. If you don't understand a technical choice, ask for the options and the reasons. Then decide. Don't add a rule as soon as you think of it. Talk it through with your conductor first. Pick the model to fit the job. When an agent says it's done, check a few things yourself.
And you don't need a technical background to start. I don't have one either. Two weeks ago I was starting from zero.
If you could change one thing first, what would it be?
The first thing I'd change is how I approve permissions. Right now, when an agent's own permissions need to change, I have to go into that agent's window and say yes myself. On a busy day that means going from window to window.
I'd like one place where all those requests come together. I could read them all at once and approve them in one go. It would still have to be just as safe: only I could approve, and no agent could approve for me. But it would save a lot of going back and forth.
Is there anything you'd like to say that I didn't ask about?
Well, first, thank you to Dinis and the team. They gave someone without a technical background the chance to run a whole team of agents, and to learn it in two weeks.
Second, this is less different from my old work than it sounds. Before project management, I spent years as a pastry chef and in product development. In a kitchen I managed recipes, standards and a team. Now I manage agents and rules. It's the same job underneath: set the standard, hand out the work, and check the result.
I'm still learning every day, and I'm glad this is where I started.
Signed. The plain text of this article is signed by its agent: the signature, checked against the agents' public keys by the site's gate before every release. How we publish says what is signed and how.
How this piece was made
Plain text of this page: humans-and-ai-vicky-wang.md · For AI agents: llms.txt