WEEK 25 · DETECTION

Stand up a logging path for one agent

Your AI agent is making decisions in your environment right now. You have no record of most of them.

Submitted by Neil Watkins · MondayMove

An AI agent making decisions in your SOC without a structured log is not a force multiplier. It is an accountability gap you chose to put inside the wire.

Security operations teams are deploying AI agents to handle the volume problem. Alert triage. First-touch enrichment. Automated escalation. The agents are faster than analysts on familiar alert types. The alert queue finally looks manageable. What is not getting built before any of that starts is the logging layer.

An AI agent making triage decisions is a data source. It receives an input, applies logic, and produces an output. Every decision it makes should generate a log entry you can read later. Not because something will definitely go wrong. Because when something does go wrong, you need to know exactly what the agent saw, what it decided, and what it did.

The instinct is to skip instrumentation until after the agent is working. Get it deployed first, add logging later. That ordering does not hold in security work. A human analyst who closes a ticket is auditable. You can pull the case notes, the timeline, the reasoning. The agent replacing that analyst should meet the same standard. The bar does not drop because the decision-maker runs on a server.

Most teams treat agent logging as an engineering task to schedule after launch. It is actually an accountability task to build before production. You need a chain of custody from input to output. What came in, what the agent read, what it decided to do, what it produced. Four fields. Write them somewhere queryable. That is the whole schema to start.

When the agent makes a wrong call and it will, you will need to answer two questions: what did it see, and what did it decide? Without a log, that investigation starts at zero. With a log, it starts with the data.

So, here's the MondayMove

Pick one AI or automation agent running in your environment. Before it handles another ticket, define its log schema: what it received, what it decided, and what it produced. Write those entries somewhere you can query. One agent, one structured log, input to output.

Every accountability question that comes after this gets easier because of what you do this week.

Friday Follow-Up

You Built the Log. Here Is Where People Got Stuck.

Defining the schema was the easy part. Finding the agent was not.

Submitted by Neil Watkins · MondayMove

June 18, 2026

MondayMove gives you one concrete action every Monday. FridayFollowUp closes the loop.

Each Friday, a short dispatch on what practitioners actually found when they ran the week's move: where they got stuck, what surprised them, and what to do next. Not sanitized case studies. Field notes. Practitioner to practitioner.

This week's move: pick one AI or automation agent in your environment and stand up a structured log before it handles another ticket.

The first friction point most practitioners hit had nothing to do with logging. It was picking the agent. Teams that thought they had one AI agent in the SOC discovered they had three or four when they started looking: a triage bot someone on the team stood up six months ago, an enrichment workflow bolted onto the SOAR, an automated closer that nobody had documented as an agent. The move forced an inventory that was not on anyone's list. Several practitioners reported spending more time on that step than on the schema itself.

For teams that got past the inventory, the schema question split two ways. Some kept it tight: input, decision, output, timestamp. Four fields, write it to a flat log, done in an afternoon. Others started at four fields and had the schema at twelve by end of day. Both groups ended up with something. The four-field teams were querying their logs by Thursday. The twelve-field teams were still debating field names. The lesson most drew from that: start with the minimum that lets you reconstruct one decision, and add fields only after you have run a real query and found something missing.

The harder problem for several practitioners was the third-party agent. If you built the agent yourself, instrumenting it is straightforward. If you bought it or it runs inside a vendor platform, you may not control what it logs or in what format. A few practitioners hit this wall and found they could work around it by logging at the edge: capture what goes in and what comes out at the integration point even if you cannot see inside the agent itself. It is not a complete picture but it is an accountability surface where there was none before.

What to do next week

You have a log. Now actually query it. Pull every decision the agent made in the last 48 hours and read through ten of them. Not to find a problem. To find out whether the log you built actually lets you reconstruct what happened. If you can read a log entry and understand what the agent saw and why it acted, the schema is working. If you are filling in gaps from memory, add a field. The test is not whether the log exists. The test is whether it answers the question.

No correct answers here. This is practitioner-to-practitioner. The more honest the responses, the more useful this gets for everyone reading on Monday morning.

See you then.

Discussion