Writing a company's rules for its agents

Picture a furniture workshop with fifteen people. The owner has run it for twenty years, and the rules are all in her head. Never order more than a few weeks of birch plywood from the cheaper supplier; their quality wanders. The foreman can approve small purchases; anything larger comes to her. A request to change a supplier’s bank account is always confirmed by phone, on a number already on file. The regular customer who pays late is never chased in writing before she has called him.

Then agents arrive to take over purchasing and reminders. Someone writes their instructions in an afternoon: “Be careful with large orders. Check unusual requests.” Within a month an agent has drafted a reminder to the late-paying regular, queued a plywood order sized for a whole quarter, and passed a supplier’s new bank details into the payment run, because the email looked exactly like that supplier’s other emails. Nothing was technically broken. The rules were never written down. The workshop is hypothetical; the pattern is not.

The real cause: rules held by habit

Every company runs on rules. Most of them were never written, because people do not need them written: they learned them by watching, and they apply them with judgement. An agent cannot inherit habit. It gets what is written, and a sentence in a prompt is not a rule. It is text a model interprets, and a persuasive email is text too.

Where rules for agents go wrong

Rules in a prompt. Instructions an agent reads are a request, not a fence. If the only thing between an agent and a payment is a sentence it was asked to follow, the boundary is as strong as the model’s reading on its worst day.

Limits without numbers. “Large”, “unusual” and “reasonable” mean something to the owner and nothing to anyone else. An agent will pick an interpretation, and it will be consistent about it.

Rules nobody owns. When a rule turns out to be wrong, who changes it? If the answer is “whoever set the agents up”, the rule will not change.

One account for everything. An agent working under the owner’s login can do everything the owner can. Its limits are the owner’s limits, which is to say none.

No record of which rule allowed what. When something goes wrong there is a result and a guess. Nobody can say which rule permitted the action, so nobody can fix the rule.

Rules copied from somebody else’s company. A template from a larger firm describes approval chains that do not exist here and misses the three things this workshop actually cares about.

How we intend to write them with you

Interview the people, not the org chart. Who actually approves what today, including the exceptions everyone knows and nobody wrote down. The foreman knows things the organisation chart does not.

Three kinds of rule. For each process: what an agent may suggest, what it may do on its own, and what waits for a person. Most of the value is in being precise about the third.

Numbers where there are limits. Not “large orders” but a limit the owner writes in, per supplier or per kind of goods, and who approves above it. If the owner cannot name a number, that is a decision still to be made, not one to hand to an agent.

Rules below the agents, not inside them. In KYBERIOS the rules live in the policy engine and in each agent’s KyberCell, outside the model: which data it can read, which programs may reach the network, which secrets are injected where. An agent cannot be talked out of a rule it never holds. How an assistant hands work to a swarm shows where the person comes back in: anything sensitive stops, and KyberBot asks.

Every action tied to a rule. Each step an agent takes is recorded together with the rule that allowed it, as every step on the record describes. When a rule is wrong, the record shows which one.

Plain text, versioned, with an owner per rule. The rules sit in the company’s own repository, readable by the owner, the accountant and an auditor. Each one has a name next to it and a history of its changes.

Start narrow, widen with evidence. Read-only first, then drafts a person approves, then action within limits, one process at a time. Processes run as swarms describes the agents’ side of that progression.

Review after every surprise. Each time an agent does something nobody expected, the first question is which rule allowed it and whether that rule is still right.

Writing these rules is part of every deployment we intend to run, and it is the part a company keeps if it ever leaves us. It is one step of what a Kyber deployment looks like. Nothing is on offer yet; the KYBERTIS homepage has the honest state of the work.

A test you can run today

Pick one process that spends money, such as paying a supplier invoice. Write down every decision in it, from the invoice arriving to the money leaving, and next to each one: who makes it today, and the limit, as a number, if there is one.

Then count two things: decisions with no number, and decisions only one person knows how to make. Those are the rules an agent would have to guess. Write them down first, whether or not you ever deploy an agent.