AI agent platform: several agents, one supervision

Yes, and it is the most ordinary defect of an open platform.
What I record: 4 agents run on a broadly entitled service account, chosen because it "worked". Their creator, meanwhile, has no access to part of what their agent reads.
What that produces: a person can obtain, by asking their own agent a question, information they could not have opened directly. It is not an intention: it is a consequence, and it is invisible from both sides.
What I do: an agent cannot have more rights than the person it works for. Where it acts for several people, it applies the rights of whoever is asking, not its own.
What it changed: of the 4, 2 went on working identically — the broad rights were not being used. 1 lost access to a source, which was reopened to it explicitly. The last was stopped: it should not have existed in that form.
What I then measure: the gap between rights granted and rights actually used. Across 41 agents, 29 use less than half of what is open to them — and an unused right is one that can be withdrawn without breaking anything. 4-agents_29-underusing.pdfA consequence invisible from both sides
⛓ Source · 4 agents with excess rights, 29 using less than half

Three departments created the same agent, each with its own reading of the rule.
What I record: three agents handle the same question — eligibility for a discount — and give three answers depending which department is asked. Each applies a defensible rule: one follows the standard contract, another a 2024 internal note, the third a commercial practice.
What that produces: a customer who asks in two places gets two answers. None of the three agents is wrong within its scope — it is the company that has three rules.
What I have costed so the choice can be made in one meeting: for each of the three rules, its source and date, the number of answers it has produced, the customers concerned, and the discount gap in euros between the three readings. The single rule is signed by whoever owns the subject: it is not a technical arbitration, and taking the most recent or the most frequent would mean settling a commercial question from a platform.
What I do: I pass the three rules to whoever owns the subject, with the three sources and the number of answers each has given. Then I mark the subject "rule not unified", visible in the inventory, until it is settled.
What the platform prevents in future: creating an agent on a subject already covered without its creator being told. Not forbidden: flagged. Over six months, 9 creations were abandoned after that flag. 3-rules_9-creations-abandoned.pdfNone of the three is wrong: the company has three rules
⛓ Source · 3 agents, 3 differently sourced rules, 9 creations abandoned

Because an agent never reports that it has become wrong.
What I record: 11 agents have no review date. The oldest has run for 22 months on its first day's rules.
What changed around them, and not in them: a price, a threshold, a rewritten internal procedure, a form whose fields moved. The agent goes on applying what it learned, and it does so very well.
Why it does not surface: an agent that has become wrong produces plausible answers. They are not visible errors: they are answers consistent with a rule that no longer exists. The only moment anybody notices is when somebody compares them with the current rule.
What I do: every agent carries a review date and an owner. At the deadline the agent goes on working — I cut nothing — but it is marked "not reviewed" in the inventory and in its internal answers.
What that produced: at the first review campaign, 7 agents out of 30 were applying at least one obsolete rule. Two of them for over a year. None had caused a detected incident. 11-without-review_7-of-30-obsolete.pdfAn agent that has become wrong produces plausible answers
⛓ Source · 11 agents with no review, 7 of 30 with an obsolete rule

I can flag it and prepare its shutdown. I do not stop it.
Why: because the question is never "should it be stopped" but "what depends on it". Across the 41 agents, I can answer for 24. For the other 17, nobody can — which is exactly the orphaned-agent problem.
What I prepare before any shutdown: what the agent reads, what it writes, who calls it, and what stops with it. That document takes an hour when the agent is declared, and it is impossible to produce when it is not.
What I propose instead of a shutdown: an observation period — the agent keeps running, its calls are counted, and we see who uses it over a month. Of 5 agents put under observation, 3 received no calls at all and were stopped safely; 2 served a department that did not know it depended on them.
What I do with the "may", because it is what has to be resolved before a shutdown and not after: the 17 orphaned agents have gone under observation, and the call record lands in a month. You will then stop them on a number of calls, not on a cost — an agent that costs little and serves nothing stops safely; an agent that costs little and serves a department that does not know it takes that department down with it. 5-under-observation_3-with-no-calls.pdfThe question is not "should it be stopped" but "what depends on it"
⛓ Source · dependencies known for 24 agents of 41, 5 under observation

Yes. It is closed by default, it opens with one line, and I give you both versions of the table before you choose.
What I open if you ask: usage per person and per department, the call detail, and an adoption ranking if you want one. It is lawful — the French DPA restates that an employer has the power to frame and monitor staff activity — and I supply the prior information notice (art. L1222-4) and the works council consultation file, half a day of work you will not have to do.
What I show you first: in organisations that opened the adoption ranking, call volume rose without the number of tasks actually completed moving. A department compared on its adoption runs agents to appear in the table.
What I propose instead, answering the same question: tasks completed per agent, time given back per department and agents nobody uses. Marc Delaunay, who chairs your committee, chose that one — and it allowed 3 agents with no calls to be stopped within a month.
Both are available. You can even have both at once. opening-usage_both-tables.pdfWhat opens with one line · the observed effect · works council file ready
⛓ Source · French DPA, art. L1222-4 · works council file supplied · 3 agents safely stopped

It made forty-one agents steerable, and it stopped what no longer served.
What was recovered: 17 orphaned agents got an owner back — eleven created by somebody who changed role, four by a contractor whose engagement has ended. They were reading data, six were writing it, and nobody knew what depended on them.
What was stopped: 5 agents placed under observation, 3 with no calls at all in a month, stopped. The other 2 served a department that did not know it depended on them — which is exactly why nothing is cut before looking.
What was avoided: 9 agent creations abandoned in six months, after a flag that an agent already covered the subject. Flagged, not forbidden — the creators decided for themselves.
What you keep: the inventory with owner, scope and review date, rights granted against rights used — 29 agents of 41 use less than half of what is open to them, that many rights withdrawable without breaking anything —, known dependencies, and the record of who declared what.
That last one will serve you most: it is the only thing that answers, two years later, "who decided this?". what-the-platform-gives-back.pdf5 items kept · 3 capabilities openable with one line
⛓ Source · 17 agents given owners, 3 safely stopped, 9 creations avoided

The shared foundation — and that is exactly what a platform adds over a pile of separate agents.
What the shared foundation carries, once, for all 41: the directory, from which every agent knows your people and your departments, at the same source as your other tools and never through a copied list; role-based rights, inherited from the person's role and never higher than theirs; audit logging, which records every read and every write in the same format for all 41; supervision, a single board where the owner, the review date and the volume handled read agent by agent. The forty-second inherits all four on day one: putting an agent into service took 27 days, 19 of them on rights, logging and connections; it now takes 6.
Deep integrations, and why they are not gateways: your 7 business systems — ERP, document management, ticketing, payroll, data warehouse, mail, directory — are connected with your own teams, field by field. Every deep integration carries its record sheet: the objects read, those left out of scope, the frequency, the technical account and the person who approved it on your side. 214 documented fields across 7 systems, and an integration whose system changes version raises a flag instead of going quiet.
The foundation is sovereign AI: inference runs on your machines, no business content leaves your network, an access right is withdrawn in one minute, and the 41 agents share the same model without sharing their data. The partitioning sits in the foundation, not in each agent's good intentions — that is what separates a sovereign platform from a collection of subscriptions.
The figure that does not flatter me: 17 agents out of 41 have no declared owner — 41 %, and the shared foundation let them start. The missing rule was mine: I checked rights at creation, not the owner or the review date. Since then, an agent with no named owner and no review date does not start. The 17 in service are listed by department with the question to put to each: 11 already have an owner, the other 6 are awaiting an answer, and I raise them again every Monday.
⛓ Sourced · 41 agents, 27 days down to 6, 214 documented fields across 7 systems