An agent that proposes and changes nothing

Until recently, every agent in Covey worked on a target system: handling tickets, writing code, checking dependencies. Version 0.4.0 added one whose subject is the workforce itself. We call it Covey Doctor.

It reads a colleague's work record — the log of what that agent actually did — together with the configuration that produced that behaviour. If an operator has entered the platform's repository, it also reads the source of the version currently running. That is the difference between a symptom and a cause: reporting that an agent often fails is cheap. Saying why requires the code.

That makes it the agent with the widest reach in the whole system. Which is exactly why it may not change anything.

What a proposal is

When Covey Doctor concludes that a colleague should be configured differently, it does not write a change. It writes a proposal.

Technically, a proposal is a complete configuration version. It is saved, it is versioned, and you can see it line by line against the running version. It differs from a normal version in one property only: it does not run. Only when a person accepts it does it become the active configuration.

One detail matters more than it sounds. Accepting writes exactly what the proposal contains — and nothing that has changed around it in the meantime. Accept a proposal from Monday on Thursday and you get Monday's proposal. Without that rule, an approval would silently pull in things nobody had read.

Covey Doctor may also write proposals about its own configuration, incidentally. What it may not do is read its own metrics — otherwise it would improve the measurement instead of the work.

Why we park actions rather than forbid them

Some actions do not reach into a target system but into Covey itself: creating an agent, changing a configuration, setting a permission. We cannot simply allow actions like that.

The first approach was to forbid them. When a rule hard-refused an action, the run ended with an error. That is safe but unusable: the agent had done work that was then lost, and on the next attempt it ran into the same wall.

Today the action is parked instead. It moves into a list where a person decides, and the agent repeats it once the decision has been made. The run does not end and the work is preserved.

The approval remembers what it was shown

That repetition, however, created a problem that had not existed before.

When a person approves an action and the agent then performs it again — how does the platform know it is repeating the same action? If the approval means only "creating an agent is allowed", then it also covers creating an entirely different agent.

So since 0.4.0 an approval records the exact values that were displayed to the person. Approving the action "create an agent with the identifier helper" is not an approval of "create an agent with the identifier backdoor". If the action comes back with different values, that is a new question rather than an already answered one.

This sounds obvious, but it is not. In many systems approvals are granted at the level of the action type, because that is easier to implement. As long as a person performs the action, that mostly works out. As soon as a program sits between approval and execution and determines the values itself, the type of action is the wrong level.

Where things land that hold nothing up

The findings from these reviews and the open approvals now live in one list, sorted by urgency. The difference between the two is stated explicitly, because in practice it matters:

An approval holds an agent up. It waits for the decision and continues afterwards. Leave it lying there and you have stopped work.

An open point holds nothing up. It is a proposal, a finding or a note, and until somebody picks it up, nothing happens. Leave it lying there and all you lose is the information.

Showing both in one list without naming that difference would have been convenient and misleading.

One last point that mattered to us: when Covey Doctor comes across something outside its own remit, it reports it to the colleague responsible. It does not quietly work around it. An agent that routes around obstacles instead of reporting them ensures that nobody ever learns about them.