Agents · Memory
Le Doyen
A team of AI assistants where each one knows what it may do, and above all what it may not.
In short
- Problem
- A single assistant you talk to about everything quickly becomes unmanageable: topics get mixed, private information spills over, and you lose track of who decided what.
- Solution
- Instead of one assistant, a small organisation: six roles, each with its scope, its responsibilities and a list of what it cannot do.
- What it brings
- Every topic stays in its place, you know who did what, and no assistant can decide on its own what becomes official.
- Where it stands
- Works and I use it every day. The supervision interface exists as a prototype.
- My role
- I designed the organisation, wrote the rules and scope of each role, and defined the scenarios to test. The code was written with assistants, under my direction.
Why this project
Like many people who use AI every day, I ended up with conversations, decisions, projects and notes scattered across a notes app, code repositories, chats and documents.
I started like everyone else, with one assistant I talked to about everything. It worked for a few weeks.
What went wrong
An assistant that touches everything has no reason to refuse anything. Three problems showed up quickly.
Topics got mixed up. A question about a work project brought a personal detail into the answer. Not a big deal when you are alone, much more awkward as soon as you need to share something.
I lost track of who decided what. When a piece of information landed in my notes, I could not tell whether it came from a decision I had made or from the assistant's own guess.
The memory filled up with guesses. An assistant that chooses what to remember ends up treating its assumptions as facts.
What I set up
Instead of one assistant, a small organisation: six roles, each with its scope, its responsibilities and a list of what it cannot do.
- A coordinator receives the request, keeps only the useful context and sends it to the right role. It handles nothing itself.
- Two domain leads, one for private matters and one for projects. They have no access to each other.
- Three experts step in without managing anyone: a controller who checks quality and security, a role that turns a vague request into a clear brief, and a tools lead who looks at what already exists before adding anything.
What makes the system reliable
It is not the number of assistants, it is what is written for each one about what it is not allowed to do.
The private lead cannot see projects, and vice versa. The controller has no permanent access: it gets limited access for the length of a check. And one rule applies to everyone: no assistant can decide on its own that information becomes official. It suggests, I approve.
It is the same idea as access rights in a company, applied to assistants. And for anyone rolling out AI across several departments, that is the real question: can the system go off the rails?
Show technical details
The registry
The organisation is described in a versioned registry that is the reference. For each role: an identifier, its domain, what it can see, who it can call, who can call it, its responsibilities and its restrictions. The fifteen sub-agents each depend on a single role and cannot be called from another domain.
Routing
The coordinator does not handle requests; it passes them on with only the context needed. An ambiguous request is sent back to be clarified, rather than handled half-right by the nearest role.
Tests
They check that each request goes to the right place, and above all that an out-of-scope request is refused. Checking that one lead cannot read the other's space matters more than checking that it reads its own correctly.
Numbers
6
roles
a coordinator, two domain leads and three cross-cutting experts
Source · le-doyen-v1 architecture registry
15
sub-agents
five for the private domain, ten for projects
Source · le-doyen-v1 architecture registry
11
shared rules
binding on every role, whatever its domain
Source · le-doyen-v1 architecture registry
19
tools listed
inventoried and reused before adding a new one
Source · capability registry
What I did
Architecture
I split the system into a coordinator, two domain leads and three cross-cutting experts.
Agent design
For each of the six roles and fifteen sub-agents, I defined what it can do, who it can call and what it is forbidden to do.
Rule design
I wrote the eleven shared rules, including the ban on any assistant approving information on its own.
Assisted development
The server and request routing were written in TypeScript with Claude Code and Codex, under my supervision.
Testing
I defined the scenarios to test, especially those where a request must be refused.
Documentation
I kept a registry that is the reference for roles and rules.
Evidence
A registry that is the reference
verifiedA single file describes the roles, what each one can see, who it can call and what it is forbidden to do. No assistant can make up its own scope.
- Source
- agent-registry.json, versioned schema
- Verify with
- Read the registry and compared it with how the system actually behaves.
Written restrictions for every role
verifiedThe private domain lead has no access to projects, and vice versa. The controller has no permanent access.
- Source
- restrictions field of the architecture registry
- Verify with
- Read the registry, then checked that the tests refuse cross-access.
Tested scenarios
verifiedTests check that a request goes to the right role, and that an out-of-scope request is refused rather than handled half-right.
- Source
- system test suite, Doyen and Lucius scenario files
- Verify with
- Suite run on 30 September 2026: 24 routing scenarios and 12 capability scenarios, all passing.
Limitations
- The supervision interface is still a prototype. Today, the system is mostly run from the command line and the editor.
- Some integrations are not finished.
- The system depends on external tools: if a model provider changes its interfaces, part of it has to be redone.
- It is built for far more information than it holds today. It gains value with use.
- It is a personal system; it has not been tested with several users.
What I take away
- The right question is not "what can this assistant do?" but "what must it be unable to do?". Writing the restrictions before the capabilities changes the whole design.
- A coordinator that routes without mixing everything up beats an assistant that knows everything. You lose a little comfort and avoid a lot of mistakes.
- Taking away every assistant's right to approve information is what keeps the system reliable over time.
What it could bring to a company
- A sales team can separate client accounts, internal decisions and contracts the same way, with different rights for each.
- A company rolling out AI assistants across several departments can write down each one's restrictions, so none of them spills into another's scope.
- Any organisation that must keep a record of its decisions can require human approval before information becomes official.
Technologies
- TypeScript
- Node.js
- Model Context Protocol
- Zod
- Vitest
- Obsidian