Processes as swarms: orders, invoices and stock run by agents

Picture month end at a small signage company. The owner has had enough of chasing invoices by hand, so a helpful nephew sets up an automation: every morning it reads the bank statement, compares it with the invoice list and emails a reminder to everyone who has not paid. It works for three months. Then the statement arrives a day late, the automation sees no payments at all, and forty customers get a reminder, including the one who paid early and the one in the middle of a dispute about a misprinted banner.

The next idea is bigger: give an assistant the owner’s login to the mailbox, the invoicing program and the bank, and tell it to “handle receivables”. It is more flexible. It is also one convincing email away from paying a fake invoice.

The real cause: a process is not one task

Chasing invoices looks like one job. It is really a dozen: read the payments, match them to invoices, find the partial ones, check which customers are in a dispute, decide who gets a reminder and in what tone, draft it, have someone approve the ones that matter, send, record. Each step needs different data and different permissions, and some of them need a human.

A script squeezes all of that into one fixed path with one set of keys. A single bot squeezes it into one long conversation with all the keys. Neither has a plan you can read, a boundary the system enforces, or a record of what happened.

Where process automation goes wrong

One bot with every key. An agent holding the owner’s credentials can do anything the owner can. A sentence in its prompt saying “never pay anything” is a request, not a fence, which is the point of policy, not prompts.

A script that cannot ask. Fixed automation does exactly what it was written to do, including when its input is wrong. It has no way to stop and say “this looks odd”.

A long job in one head. One agent working through a month of invoices carries every document it has read. By the afternoon its context is crowded with history, and its decisions get worse.

Rules in the wrong place. Limits written in a prompt, in a spreadsheet macro and in one person’s memory are three different rulebooks. None of them is enforced below the thing taking the action.

No trajectory. When the wrong customer gets the wrong email, there is a chat log and a guess, not a list of what ran, what was read and which rule allowed it.

A process as a swarm

In KYBERIOS each process runs as a KyberAgent swarm, the pattern described in a swarm, not a bot, under the company’s own policies.

A planner writes the job down. “Close receivables for September” becomes a to-do list in a file: match payments, flag partials, check disputes, draft reminders, collect approvals, send, record. The list can be read mid-run, and a person can change it.

Sub-agents take one item each. The agent matching payments starts with a fresh context and only the bank lines and the open invoices. The agent drafting reminders sees the matched list and the customer notes, not the bank. Each one returns a single report.

Every agent works in its own cell. A KyberCell is sealed when it is created: fixed files and programs, network closed except for the one address a rule allows, secrets added only where an authorised call leaves the cell. An agent in a cell goes through it in detail.

The company’s policies sit below the agents. Reminders to customers in a dispute wait for a person. Anything above a written amount waits for the owner. A late or empty bank statement is a reason to stop, not to send. The policy is plain text, versioned, and the same for every process.

People are asked through their KyberBot. When the swarm reaches something sensitive, it stops and asks the KyberBot of the person responsible, who gets the question with the evidence attached. The agent waits; it does not guess.

Every step is on the record. What ran, what was read, which rule applied and who said yes, in order: the trajectory described in every step on the record.

Scope is earned per process. A new process starts read-only: the swarm proposes and a person decides. When the record shows it has been right for long enough, the boundary moves for that process only, with a limit, and it can move back. A homeostat watches the error rate and narrows the scope by itself when corrections pile up.

The same shape runs orders (check stock, credit and price, reserve, confirm), stock (count, reconcile, reorder within limits) and the month end (gather, reconcile, list what needs a human). None of it is released yet; the homepage has the honest state of the work.

A test you can run today

Pick one automation, script or assistant that does something in your business without a person pressing the button. Answer five questions about it:

1. Whose credentials does it use?
2. What can it reach beyond what this one job needs?
3. What does it do when its input is wrong or missing: stop, or carry on?
4. Where is the record of its last run, step by step?
5. Could you change its limit, such as the largest amount it may touch, without changing its code?

Every “I don’t know” is a place where the process runs on luck. That is where a swarm with a plan, a cell and a policy would start.