The agent learned the workaround. Now it's company policy.

For years the complaint was the same. Too much of how the work gets done lived in people's heads and nowhere else. New engineers spent months learning which systems were reliable, which process steps mattered, who to ask, and which documented path nobody used.

Agents offer a tempting answer. Capture the procedure, encode the runbook, feed in the internal context, turn what the experienced people know into something every workflow can reach.

That's a good project.

It's also the moment to be careful about what exactly is being preserved.

Not all of it is expertise

Some of what lives in people's heads is judgment. When a rule applies. Which failures are worth chasing. What a system does under load that no document describes.

Some of it is not.

Some of it is a workaround for a limitation nobody got funding to fix. Some of it was correct under a constraint that disappeared two years ago and stayed in the routine because nothing forced a review. Some of it is one team's method for getting around another team's system, which works, and which nobody would defend out loud.

Undocumented knowledge is a record of how an organization survives. That's related to how it should work, but it isn't the same thing, and the gap between them is where most of the interesting material lives.

Encode all of it and you haven't documented how the company works. You've made the reasons it works badly executable.

A workaround behaves differently when someone knows it's a workaround

An experienced engineer carries a procedure and its provenance at the same time.

Yes, we do X before Y. That's because of a deployment limitation on the old platform. Don't do it that way on the new service.

That second half usually exists nowhere except in that person's head. It's what lets them recognize the day the rule stops applying.

What usually survives encoding is the first half: when condition X occurs, perform Y.

The instruction survives. The provisional status doesn't.

A person can hold uncertainty about their own procedure. They can think this is odd but here's why, and change their mind when the why goes away.

An encoded instruction doesn't carry that skepticism unless we give it somewhere to live.

What happens when the workaround gets fixed

Say the platform team fixes the underlying limitation.

People stop using the old path, unevenly and over a few months, the way habits change. Somebody mentions it in a channel. The knowledge propagates through the same social mechanism that put it there.

Unless we've connected the two, the encoded procedure doesn't participate in that.

The fix landed in a repository. The procedure lives in a file nobody thinks of as code.

I've seen the version of this that took a year to notice. A deploy ordering rule written for a platform limitation outlived the platform by four releases. Every runbook still said do it this way. Nobody was wrong. Everybody was following the instruction that had once been right.

Nothing is hallucinating. Nothing is violating policy. The system is doing exactly what the organization taught it to do, on schedule and without variance.

That's a difficult kind of failure to find because every individual step can look correct.

The workaround becomes the durable version of the process, and the fix becomes something only some humans know about.

Classify before you encode

Before I encode a procedure, I want to know what kind of thing I'm looking at.

Is this a policy somebody deliberately chose? A preference that's one reasonable option among several? A workaround for something we haven't fixed? An emergency procedure that's only correct under unusual conditions?

Those don't have the same lifecycle.

A policy should persist until someone changes the decision. A preference should be easy to override.

A workaround should be trying to die.

An emergency procedure should be reconsidered even if nobody has needed it lately.

Once those things are converted into the same instruction format, that distinction is easy to lose.

And without the distinction, everything starts to look like policy.

Give the procedure enough context to be questioned

If procedural knowledge is going to execute in production, I want to know why it exists.

What makes it valid? What would make it stop being valid? Who owns it? When did someone who would know last confirm it? What supersedes it if something changes?

Most of that already exists in a good runbook.

It's also exactly the kind of information that's easy to strip away during conversion because the executable steps look like the useful part and everything around them looks like preamble.

The more authority an encoded procedure has to affect real work, the more its provenance matters. Something an agent can repeatedly execute against production deserves more scrutiny than something sitting in a wiki waiting for a person to read it.

For consequential procedures, the more interesting question is whether the reason can be checked.

Some workarounds exist because of a specific, testable fact.

This service can't accept that payload. That endpoint has no idempotency key. This queue can't handle messages above a certain size.

Those aren't just explanations. They're assertions about the system.

If the procedure exists because an assertion is true, checking that assertion gives us another way to discover when the procedure may no longer belong.

The prose says why this exists.

The assertion tells us what would have to change for us to question it.

Connect the procedure to the thing it depends on

A workaround exists because of something.

A platform limitation. A missing capability. A service that couldn't do a thing. A dependency that behaved a certain way.

When that dependency is known at the time the procedure is encoded, record it.

Then the fix has somewhere to arrive.

When a team removes a constraint, the change that removes it can surface the procedures that named it. Once that relationship exists as structured data rather than only as prose, finding what a change may have invalidated becomes a query instead of a scavenger hunt.

Without that link, the mechanism connecting a fix to the procedures it obsoletes is somebody remembering.

Which is where this started.

When the system writes its own procedures

Everything so far assumes a person decided what to encode.

Increasingly, that isn't the arrangement.

Systems can take successful agent runs and turn what worked into something reusable. The agent completes a task, the run is distilled into a procedure or skill, and the next agent gets to start with what worked before.

That's useful.

But consider what qualifies the behavior for promotion.

Usually, some version of: the task succeeded.

Succeeding is not the same as being right.

An agent that finds an odd path around a broken dependency may successfully complete the task. From the outside, that run can look exactly like a good one if success is the only thing being measured.

Observed behavior, successful behavior, and approved behavior are not automatically the same thing.

So I don't want a successful run becoming an executable procedure simply because it succeeded.

Generated procedures can enter review first. Preserve why the behavior worked and what it depended on. If multiple procedures apply to the same situation, make the precedence explicit instead of leaving the choice to whichever one happens to surface first.

And don't only teach the library how things enter.

A failed validity check, a removed dependency, or evidence that a procedure is no longer used should be able to push it back toward review or retirement.

A system that can learn but can't unlearn is going to accumulate history as policy.