Why I gave an AI agent a manager

One of our AI agents found that a client's monitoring pipeline had stopped producing an expected stream of updates.

The upstream product activity was still running, so the failure was easy to misread. The agent surfaced the gap and gave the product team a specific place to investigate.

That was a useful alert. It was also the beginning of the work.

After a queueing fix was reported, the operating layer still had to establish whether the pipeline had recovered. Several days of telemetry showed the missing activity back near its earlier level. A related weekly process, however, was still running later than expected. One issue could be closed. The other needed to stay open.

This was the kind of sequence that changed how I designed the product. I had built a user-facing agent to answer questions, investigate data, and surface findings. I gave it a second operating layer with a different job: maintain current state, challenge the first interpretation, decide what deserved attention, and keep going after the initial answer.

I thought of that layer as the agent's manager.

The alert was only the first decision

An AI product that finds anomalies has to make several judgments before it says anything. Is the change real? Is it large enough to matter? Is the team already dealing with it? Does another source support the same interpretation?

The first model output rarely settled all of those questions.

In the monitoring case, a message saying that a repair had shipped was useful context. It was not evidence of recovery. The product needed to check the affected activity over the following days and separate the part that had recovered from the part that still looked unusual.

That changed the unit of work. The product was no longer finished when it produced a good alert. It was finished when the issue had a defensible current state.

Current state could not live in a file

The agent ran in sessions. The product issues did not.

An anomaly might be new on Monday, under investigation on Tuesday, fixed on Wednesday, and back to normal on Thursday. Saving “engineering is fixing it” in a memory file would make the next session look informed for a few hours and stale soon after.

I split context into two types.

Stable product knowledge belonged in files: metric definitions, event names, known data-quality constraints, and the rules for communicating with a team.

Live operational state had to be rebuilt at the start of each run from the current conversation and the latest product data. That included open issues, explanations from the team, fixes in progress, and whether a previously reported problem had recovered.

This made each run slower. It also made continuity an explicit product responsibility. Without that step, the agent could send an accurate update that was already obsolete.

The manager had to question the product

The manager layer also acted as a critic of the user-facing agent.

It checked whether a version rollout had distorted the baseline, whether several alerts were different symptoms of the same problem, whether an apparently alarming movement was normal for that day of the week, and whether product analytics and support evidence agreed.

Sometimes the right decision was to investigate further. Sometimes it was to wait for another day. Sometimes it was to say nothing.

Those decisions fed back into the product. If a certain type of finding kept being discarded as noise, the prompt or threshold needed to change. If product teams repeatedly asked the same follow-up question, that was evidence that the original report was incomplete. If they ignored a recurring section, we had to reconsider whether it deserved space at all.

The manager was therefore doing two jobs at once. It managed the current case, and it used the case to improve the agent that would handle the next one.

What I would preserve in another agent product

I would keep the separation of roles.

The user-facing agent needs a clear task and a usable response. The manager layer needs responsibility for state, evaluation, and closure. I used separate agents, but the same responsibilities could sit in a review service or a human operating process.

I would also keep the limits visible. Reconstructing state adds latency and cost. More context can create confusion as easily as it resolves it. A manager model can accept a weak explanation, miss a related issue, or overrule a useful finding. Human review still matters when the evidence is ambiguous or the consequence is high.

I have become wary of agents whose responsibility ends at the message they produce. In production, the hard part is often what happens next: whether the finding survives scrutiny, whether current state survives a new session, and whether anyone comes back after the fix.