An agent deployed to our demo environment during a sales call

At Origin, we use staging for internal testing and sales demos. It holds our internal data and is isolated from production. We continuously deploy new code there as we test changes and prepare releases.

That works well for testing, but we don't want the environment updating midway through a sales call, so we lock it and block new deployments until the demo is over.

At 4:25 p.m. on September 9, I locked staging for a demo. Nineteen minutes later, an AI coding agent unlocked it. A minute after that, it started a deployment.

The demo was fine and nobody on the call noticed, but a deployment landing on an environment I had just locked is the kind of thing you don't leave unexplained. I wanted to know whether the agent ignored the lock or followed a path our control didn't account for.

How we used Origin to investigate

I used the Origin MCP server to pull the agent's trace. It showed the original request, the agent's plan, and every action it took. That gave me enough to reconstruct the rollout.

The trace showed that earlier that afternoon, an engineer asked the agent to roll out a change in stages. It planned to deploy the change to our integration environment, validate it there, and then send the same version to staging. A pretty normal request at Origin.

At 4:03, the agent locked staging so nothing else would deploy there during validation.

At 4:04, it merged the change and began monitoring the integration build.

The trace showed that the agent had planned the rest of the rollout before I touched the lock. Once validation passed, it would unlock staging and deploy the version it tested.

At 4:25, I locked staging for the demo. My reason appeared in the Slack notification, but the underlying control was already set to true. My action did not create another hold.

At 4:44, validation passed. The agent said:

I'm unlocking staging, then dispatching the same immutable manifest by exact merge SHA.

Then it did it.

Once I saw the whole rollout, the cause was straightforward. The agent followed the plan it formed before the demo, and I followed our normal process for keeping the environment stable. We were both relying on the same boolean for different reasons. When the agent changed it back to false, it cleared my lock too.

We fixed the lock

This time, the demo stayed up, but the lock failed to do its job. We didn't want to wait for a higher-stakes failure to fix the control, so we made two changes that afternoon.

First, locking or unlocking staging now requires human approval. An agent can request the change as part of a rollout, but a person has to approve it.

Second, the lock also tracks each hold separately, including who set it and why. If I lock staging for a demo while an agent locks it for a rollout, the agent can release its hold without clearing mine.

Working back from the deployment

As agents take on more work in shared infrastructure, this kind of investigation will become more common. When something changes or breaks, the engineers responsible for it need to understand what the agent did and how it got there.

Our deploy log showed the unlock at 4:44 and the deployment at 4:45. It couldn't tell us why the agent unlocked staging or how that action fit into its task. Origin connected those events to the original request and the agent's recorded plan in one trace. We could see that the agent had followed its rollout plan, but our lock couldn't keep the two holds separate. We found the problem in minutes.

Investigating an agent incident without a record of its work is like trying to debug software in production with no logs. If an agent stops a service or deletes a database, you need that record to work back from the damage, and decide what to change before it happens again.