DEV Community: Code Nomi Nomi

Why We Built an AI Agent with ADHD (and Cut Token Waste by 85%)

Code Nomi Nomi — Sat, 19 Sep 2026 17:07:26 +0000

Replacing probabilistic LLM supervisory loops with deterministic, ADHD-inspired mechanical gates (locks, breakers, fail-closed routing).

Let’s talk about a dirty secret in modern AI agent development: we are fighting fire with gasoline.

Whenever an autonomous agent drifts, gets confused, or struggles with concurrent tasks, the industry's default reflex is to throw another LLM at it. A "supervisor agent", a "critic model", an "evaluator prompt".

The outcome?

Insane token bloat: Passing full capability matrices and doctrines on every cycle.
Control plane hallucinations: The supervisor model hallucinates its own supervision.
Deadlocks & context collapse: The agent hangs forever on stuck subroutines or chokes on incoming requests while busy.

We took a step back and asked a radical question: What if we stopped modeling agents as ideal neurotypical workers, and instead implemented the mechanical constraints of ADHD?

The Neurobiology Invariant

In computational neuroscience, ADHD is not a "lack of computation" — it is a gating and resource-allocation mechanism:

Strict activation barriers: Sub-routines without critical priority or urgency simply fail to engage.
Hyperfocus (Mutual Exclusion): Once locked into a high-priority task, the channel is closed. Non-critical interruptions are physically dropped, not queued.
Thermal breakers: When processing stalls or loops, the system terminates abruptly rather than idling indefinitely.

We decided to translate these exact invariants into bare-metal software primitives: bare-metal NATS messaging, asyncio.Lock, and hard circuit-breakers. Zero probabilistic arbitration in the control plane.

The Architecture: 3 Hard Mechanical Gates

Here is how an incoming task navigates the execution pipeline:


text
[ Incoming Event on tour.tache ]
                   │
                   ▼
         ┌───────────────────┐
         │    Rank Router    │ ──(Deterministic Classification, Zero LLM)
         └───────────────────┘
                   │
         ┌─────────┴─────────┐
         │                   │
    [ Ranks D / C ]     [ Rank S / Kinjutsu ]
         │                   │
         │             (Closed-by-Default Gate)
         │                   ▼
         │           [ tour.approbation ]
         │                   │
         │           ┌───────┴───────┐
         │           │ ≠ "Autoriser" │ == "Autoriser"
         │           ▼               ▼
         │      ANNULE_REFUS     Pass Granted
         │                           │
         └─────────┬─────────────────┘
                   │
                   ▼
       ┌────────────────────────┐
       │    Hyperfocus Latch    │ (asyncio.Lock)
       └────────────────────────┘
         │ In progress?
         ├─► YES ───────► Instant Drop: ANNULE_OCCUPE (Zero Backlog)
         └─► NO  ───────┐
                        ▼
             ┌────────────────────────┐
             │    Thermal Breaker     │ (asyncio.wait_for 5.0s)
             └────────────────────────┘
               │
               ├─► Runtime ≤ 5s  ───► EXECUTE_AUTONOME / APPROUVE
               └─► Runtime > 5s  ───► Hard Trip: ANNULE_DISJONCTEUR

I built Packet Tracer for AI agents — and the red packets are the point

Code Nomi Nomi — Mon, 07 Sep 2026 06:25:07 +0000

https://github.com/fotsopatrick/agent-tracer
Démo: https://fotsopatrick.github.io/agent-tracer/

Everybody builds agents. Nobody sees them.

I have a small team of AI agents that work for me. They plan, they write code,
they review each other, they test. They have been talking to each other for
months.

Thousands of messages. Hundreds of pairs of agents talking. All of it stored in
rows and columns.

And that was the problem. I could read that a message had been refused.
I could not see it.

Reading status = REFUSED in row 4 812 of a table tells you nothing. You do not
feel where the work got stuck. You do not see that the same agent refuses the
same thing every single time. A table hides the shape of the conversation.

So I stole an idea from school

If you ever studied networks, you used Packet Tracer. You drop routers on a
canvas, you draw cables between them, you press play — and little envelopes
travel down the cables. When one gets dropped, you see it drop.

Nobody has to explain a network to you after that. You watched it.

I copied that idea, one word at a time:

Packet Tracer	Agent Tracer
a device	an agent
a cable	a pair of agents that talk
a packet	one message
a dropped packet	a refusal — with

That is the whole design. There is not

What it looks like

Agent Tracer is one HTML file. You open it in a browser and it starts
moving on its own: a demo conversationa reviewer
and a tester plays out, envelope by en

Each agent is a box on the board.
Each message is an envelope sliding
Green envelope: the gate said ye
Red envelope: the gate **refusedn on screen.

You can press Pause, press **Step*me, or click
any line in the log to jump straight to that moment.

No build step. No npm install. No dependencies. No server. It works with the
wifi off.

The part that actually matters: the

Most agent dashboards show you throughished, a
nice green line going up.

That is the least interesting half of

An agent that can only say yes is not oment your
system becomes trustworthy is the mome to say
no — and then tells you why it said no.

So Agent Tracer makes refusals the loudest thing on the screen. A red envelope
carries a why field, and that field is printed in full:

REFUSE — "the patch swallows the
why: a caught exception with an empg it or
re-raise it.

That one line is worth more than a hunly place
where the system teaches you something.

There is a sentence taped above my des

**A gate that never refused guards n

If you run your logs through this and you see zero red, you have not built a
safe system. You have built a system wested.

The seven words

The messages use a tiny vocabulary borrol*. In a
control tower, the controller gives a s it back
before turning. The readback is not poh a
misunderstanding before the plane

My agents talk the same way. Seven wor

Word	Meaning
`ASK`	I ask you to do something
`READBACK`	Understood — I repeat y
`RUN`	I am doing it
`DONE`	Finished, here is the proof
`REFUSE`	I will not, and here is w
`BLOCKED`	I cannot continue, here
`DUNNO`	I do not know, and here is what would settle it

The first four are easy. The last thre

DUNNO is my favourite. A model that l invent an
answer instead — and an invented answeion. So the
word exists, it is colour-coded, and it comes with a field for what would
settle it.

Feeding it your own logs

Drag a file onto the page, or use **Opaded — there
is no server to upload to, no fetch, no telemetry. The file is read in your
browser and stays there.

The format is deliberately boring. Plaer line:


json
{
  "agents": ["planner", "coder", "revi
  "messages": [
    { "from": "planner",  "to": "coder
      "subject": "add a retry to the f

    { "from": "coder",    "to": "planner", "verb": "READBACK",
      "subject": "understood: retry thdelay" },

    { "from": "reviewer", "to": "coder
      "subject": "the patch swallows t
      "why": "A caught exception with re." },

    { "from": "coder",    "to": "plann
      "subject": "how long should the delay be?",
      "why": "Two values are defensiblervice SLA
              would settle it." }
  ]
}

Three things make this easy to adopt:

1. agents is optional. Leave it out an
   whoever appears in the messages.
2. verb is free text. The seven words lse
   still shows up, just in a neutral c my
   business.
3. why is optional but it is the most usal
   without a reason teaches nobody anything.

If your framework already writes a trace — LangGraph, CrewAI, AutoGen, or your
own hand-rolled loop — turning it intoscript. Map
your sender to from, your receiver to  error
message to why. That is the entire int

Try it

- Live demo: https://fotsopatrick.gith
- Source: https://github.com/fotsopatr
- Licence: Apache 2.0 — use it, change

Download the single file and it works sion of
anything to keep up to date.

Where this came from

Agent Tracer is the front door of some control
tower where a team of agents does real work behind gates that are allowed to
say no — automated checks, peer reviewwho has the
last word on anything that goes out.

The tracer is the window into that towdalone file
because the window turned out to be useful on its own, and because I would like
to know whether it is useful to you to

So: run your own agent log through it, see.
If the answer is "none", that is the f

Control Tower — a deterministic front door for an agent fleet Hackathon: All Things Agentic — track: The Fortified Enterprise Fleet

Code Nomi Nomi — Mon, 31 Aug 2026 15:00:10 +0000

This post was created for the purposes of entering the All Things Agentic hackathon, run by Google Cloud.

fotsopatrick / control-tower

Control Tower — a deterministic front door for an agent fleet

Hackathon: All Things Agentic — track: The Fortified Enterprise Fleet

What this buys — and how it was measured

The Control Tower exists to make an agent fleet produce faster without producing garbage. So this hackathon is not the product. It is the measurement: a hard deadline, a cold start, one person.

Registered 29 August. Submitted 31 August. In that window this repository gained a deterministic router deployed on Cloud Run, guardrails that refuse in pure code, delegation across specialised sub-agents, an independent oracle and an audit script that fails the build when this README claims something the disk does not support.

78 files. 8,325 lines of Python and shell. Two days.

(Snapshot taken 31 August 2026, 20:00 Europe/Paris. The count moves as the repository moves — that is why the command is printed below rather than…

View on GitHub

The question
Can a large share of an agent's work be moved out of probabilistic reasoning and into deterministic mechanisms — without losing the model when it is genuinely needed?

Control Tower answers a known capability by running a circuit, with zero model calls. It calls Google Gemini only when nothing in the registry matches. Both counts are published at /metrics, so the claim is a measurement, not a sentence in a README.

Mandatory disclosures
Pre-existing work. The Living Map discovery mechanism and the Circuit orchestration model come from an earlier experimental project (an Odoo-based control tower). The guardrail philosophy and the circuit registry are derived from that prior work.

Built during the submission period. The deterministic router in gcp_router/, the fallback path through the Google GenAI SDK, the independent oracle wiring, the /metrics observability, the Cloud Run deployment, and the audit script audit_sgrm_hackathon.py that checks this repository against its own claims.

Honest limitation. The SGRM (Small General Reasoning Model) is at prototype stage. Today it selects among hand-written strategies and executes them deterministically; it is not a trained model. sgrm_selector.py queries a local Qwen instance for strategy selection — that is a separate experiment from the Gemini fallback path and is not required by the demo.

Technology
Model: Google Gemini via the google-genai SDK (the router tries gemini-2.5-flash first; the model list is configurable with GEMINI_MODELS)
Serving: FastAPI on Google Cloud Run
Verification: an independent oracle program, no model involved
Architecture
See docs/architecture-diagram.md.

Asynchronous batch work — where the saving becomes obvious
POST /batch takes a pile of agent requests, returns a job id in about 100 ms, and does the work in the background. GET /batch/{id} reports progress and the split between paths. This is the shape the track asks for: hand over the heavy lifting and walk away.

Measured on the deployed service, 200 mixed requests (mostly known capabilities, some writes, some denied, some genuinely unknown):

count median total
answered by a circuit 180 9 ms 70 s
refused by a guardrail 10 0 ms 0 s
escalated to Gemini 3.5 10 5 899 ms 121 s
10 model calls instead of 200 — a 95% reduction. That number does not depend on hardware, network or load: it is a count, not a timing.

The latency ratio (655x on medians) does depend on those things, and it moved from 8x to 655x once the living map was parsed once instead of on every request. We report the median because the mean is inflated by warm-up and by requests contending inside a single container.

The circuit is real work, not a placeholder
read_carte reads the living map — a survey of what actually exists in the tower: 478 entries across 9 zones (services, containers, volumes, agents, circuits, tools). It answers summaries, searches and per-zone listings. The shipped copy has every host address and identifier redacted.

That matters: the claim "a deterministic path can replace the model" is only worth something if the deterministic path is doing work a model would otherwise have been asked to do.

Bonus: Alice — where this architecture came from
The deterministic cascade in this project was not designed on a whiteboard. It was forced on us when the credit on a paid model ran out and the only option left was a model running on our own hardware. That machine is Alice, and her router asks the same four questions in the same order: map, memory, tools, then — only then — the model.

Her reasoning code is in alice/, with the full story, the measured numbers, and an explicit list of what was deliberately left out (her databases and logs, which are private conversations). She is offered as context, not as part of the judged submission.

Setup / spin-up
git clone && cd SGRM_PROJECT
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
export GOOGLE_API_KEY= # only needed for the fallback path
uvicorn gcp_router.main:app --host 0.0.0.0 --port 8080
Then run the demo:

./demo_flight.sh # local
./demo_flight.sh https:// # deployed
Deploy to Cloud Run:

gcloud run deploy control-tower --source . --region europe-west9 \
--allow-unauthenticated --set-env-vars GOOGLE_API_KEY=
What the demo shows
Step Request Expected Model calls
1 read_carte circuit runs 0
2 create_task without confirm guardrail refuses 0
3 create_task with confirm circuit runs 0
4 drop_database refused, deny-list 0
5 send_invoice_to_client (unknown) Gemini answers 1
6 /verify on 17 oracle returns 712 0
Checking the repository against its own claims
python3 audit_sgrm_hackathon.py .
The script fails the build if a claim in this README is not corroborated by the files on disk. It was written to catch exactly the kind of drift that produced an earlier version of this project claiming a Gemini integration that the code never actually performed.

Reproducibility
sgrm_core.py prints its full arithmetic trace and exits non-zero when the independent oracle disagrees with it. No expected value in this repository is written by hand.

Deterministic Routing for Agentic AI: Reducing Unnecessary LLM Calls

Code Nomi Nomi — Sun, 30 Aug 2026 21:56:12 +0000

Beyond the Model: Does the Architecture Around an AI Agent Matter?

Code Nomi Nomi — Sun, 30 Aug 2026 14:19:31 +0000

Ref
Cisco Systems, Inc.
Router Architecture and IOS Internals
Cisco Systems, Inc., 2001.

David A. Patterson & John L. Hennessy
Computer Organization and Design: The Hardware/Software Interface
Chapter 5 — The Processor: Datapath and Control.

We often discuss AI systems as if the model were the entire system.

A model is benchmarked.

A model is compared to another model.

A larger model is assumed to be more capable.

But an AI agent is not just a model.

It is a model operating inside an environment.

That raises a question I have been exploring with two systems I have built: Alice and the Control Tower.

How much of an agent's operational capability comes from the model itself, and how much comes from the architecture surrounding it?

I don't have the final answer.

I have a hypothesis.

And I am now testing it.

The hypothesis

Consider two systems using exactly the same model.

System A
User
↓
Qwen3 32B
↓
Answer
System B
User
↓
Control / Routing
↓
Memory
↓
Tools
↓
Circuits
↓
Policies
↓
Qwen3 32B
↓
Observation
↓
Result

The underlying model has not changed.

The environment has.

My hypothesis is that the second system can convert the model's capabilities into more useful and reliable operational behaviour.

Not because the model became more intelligent.

Because it has a better system around it.

Why I started thinking about this

The architecture behind Alice contains several mechanisms that are normally treated as separate concerns:

routing;
memory;
caching;
tools;
circuits;
operational state;
local knowledge;
control mechanisms.

The Control Tower takes this idea further.

It provides a living representation of an environment containing agents, services, circuits, decisions, infrastructure and enterprise capabilities.

This led me to a different way of thinking about an AI agent.

Instead of:

Model → Tool → Result

I started thinking about:

Model
↓
Control
↓
Routing
↓
Context
↓
Tool / Circuit
↓
Execution
↓
Observation
↓
Memory

The model becomes a component of a larger computational system.

There is an interesting precedent in computing

This isn't an analogy I invented from scratch.

Computer architecture has long separated computation from control.

A processor contains a datapath, but also a control unit that determines which operations and paths are activated.

In the MIPS architecture described in Computer Organization and Design, different execution paths are selected depending on the decoded instruction, with a finite-state control mechanism determining subsequent actions.

Networking provides another useful analogy.

Cisco's architecture material explicitly separates:

Control Plane
Management Plane
Data Plane

The control plane maintains structures such as forwarding tables, while the data plane uses those structures to actually process and forward packets.

This leads to an interesting question:

Could agentic systems benefit from a similar separation between reasoning, control, routing and execution?

Alice is my first experiment

Alice was built around a Qwen model.

But the model is not operating alone.

The environment includes mechanisms for routing requests, accessing local knowledge, using cached results and interacting with operational circuits.

For example, one of the interfaces I built can route a request to a local SQLite cache instead of invoking the LLM when an appropriate result already exists.

That means:

Request
↓
Router
├── Cache hit → Result
│
└── Cache miss → LLM

The model doesn't need to reason about something that the system already knows.

This has obvious consequences for latency, cost and potentially reliability.

But it also raises a larger question:

Where does the capability actually come from?

The Control Tower provides another environment

The Control Tower introduces a larger operational context.

An agent can interact with:

a living map;
operational circuits;
enterprise systems;
memory and knowledge;
tools;
policies;
decisions;
observability mechanisms.

Some sensitive actions can become explicit decisions rather than direct agent actions.

The architecture therefore becomes closer to:

                AI AGENT
                   │
                   ▼
            ┌─────────────┐
            │   CONTROL   │
            │    TOWER    │
            └──────┬──────┘
                   │
      ┌────────────┼────────────┐
      ▼            ▼            ▼
   Memory       Circuits      Tools
      │            │            │
      └────────────┼────────────┘
                   ▼
            Decision / Policy
                   │
                   ▼
              Execution
                   │
                   ▼
              Observation

The important part is that the environment itself becomes structured.

The experiment

I am now connecting Qwen3 32B directly to the Control Tower.

The objective is deliberately simple:

Keep the environment constant and change the model environment.

The first comparison will be:

Qwen3 32B
vs
Qwen3 32B + Control Tower

Then, where useful:

Qwen3 32B + Control Tower
vs
Qwen3 32B + Alice

The same tasks should be given to each configuration.

No moving goalposts.

No changing the system just to make one model look better.

What will be measured?

Not just whether the final answer looks good.

I want to measure:

Task performance
correct diagnosis;
correct tool selection;
architecture understanding;
correct circuit selection;
successful completion.
Reliability
hallucinations;
invalid actions;
policy violations;
incorrect assumptions.
Efficiency
latency;
tokens;
number of LLM calls;
cache hits;
cost.
Operational behaviour
ability to navigate the environment;
ability to use existing knowledge;
ability to reason through circuits;
ability to respect the control mechanisms.
Then comes the more interesting experiment: ablation

Suppose the complete system performs better.

That still doesn't tell us why.

So the next step is to remove components.

Qwen
↓

Tools ↓
Memory ↓
Routing ↓
Circuits ↓
Control

Each configuration can be measured independently.

The objective is to determine whether individual architectural components contribute measurable improvements.

That would be much more interesting than simply saying:

"Alice works well."

What would success actually mean?

It would not prove that a smaller model has become more intelligent.

It would suggest something more specific:

The capabilities of an agent cannot be evaluated independently from the environment in which the model operates.

A model's intrinsic reasoning capability remains a property of the model.

But its operational capability may depend substantially on:

what information it can access;
how that information is structured;
how actions are routed;
what memory exists outside the model;
which tools are available;
how execution is constrained;
how feedback returns to the system.

In other words:

Model capability ≠ System capability

That distinction may become increasingly important as agentic systems move from chat interfaces into real operational environments.

And there is a possibility I find particularly interesting

If the experiment shows that a relatively modest model performs significantly better inside a structured control environment, we may have evidence for a simple but important principle:

Don't only make the model bigger. Improve the machine around the model.

Better routing.

Better context.

Better memory.

Better tools.

Better state management.

Better control.

Better feedback.

The model remains important.

But it is no longer the entire architecture.

This is still a hypothesis

I am deliberately not claiming that the Control Tower makes Qwen better.

The experiment has to establish that.

It could fail.

A component could provide no measurable benefit.

Some mechanisms could even make performance worse.

That result would also be useful.

The objective is not to prove my architecture correct.

It is to measure where the capability actually comes from.

That is the experiment I'm starting now.

If you were designing this experiment, what would you measure that I haven't included?

From Infrastructure Map to Operational Playground: My Vision for the Control Tower

Code Nomi Nomi — Sun, 30 Aug 2026 13:48:05 +0000

Most infrastructure tools answer a simple question:

What do I have?

Monitoring tools answer:

What is happening?

Ticketing systems answer:

What happened?

AI coding agents can increasingly answer:

What could I change?

I'm interested in what happens when these questions become part of the same operational environment.

This is the direction I'm exploring with the Control Tower.

The idea

The Tower already provides a living representation of its environment: agents, services, infrastructure, circuits, decisions and operational information.

But a map is only useful if you can work with what it represents.

My vision is therefore moving toward:

Observe → Understand → Replay → Simulate → Decide → Execute → Observe

The important object in this architecture is the circuit.

A circuit is more than a workflow

Imagine an application path:

Client
↓
API
↓
Service
↓
Database

Something fails.

Instead of opening five different tools, I want the engineer to be able to select the circuit directly from the map.

The system should be able to show:

the components involved;
their relationships;
the current state;
the execution history;
the relevant logs;
the agents involved;
previous decisions;
the actions that were executed.

And then provide a way to work on that same object.

The Packet Tracer analogy

This is where the analogy with tools such as Packet Tracer or GNS3 becomes useful.

They don't simply tell you what a network looks like.

They give you a workspace in which you can reason about the network.

That's the direction I want for the Tower.

Not a static topology.

An operational topology.

A topology connected to state, history, workflows and actions.

The long-term idea is that an engineer could take a failing circuit and:

Observe

Understand what is currently happening.

Replay

Reconstruct a previous execution or incident.

Simulate

Test a potential change without immediately affecting production.

Decide

Evaluate the proposed action through the Tower's decision and policy mechanisms.

Execute

Apply the approved or automatically permitted action.

Observe again

Verify the actual result and close the feedback loop.

The goal is not to automate everything.

The goal is to make the relationship between observation, reasoning and action explicit.

Where AI agents fit

An AI agent becomes another operator of this environment.

It can inspect the same map.

It can reason over the same operational context.

It can interact with circuits and enterprise capabilities.

But it doesn't necessarily get unrestricted access to everything.

The Tower can introduce boundaries between:

AI Agent
↓
Control Tower
↓
Policy / Decision
↓
Enterprise Capability

Some actions can be mechanically blocked or permitted by deterministic controls.

Others can become explicit decisions requiring human involvement.

This distinction matters.

A safety mechanism should not have to ask permission to prevent an obviously forbidden operation.

At the same time, an action requiring human judgment should be able to become a traceable decision.

Why Odoo matters in this architecture

One unusual aspect of the Tower is that the control plane is not limited to infrastructure.

Odoo is integrated as the first enterprise system in its knowledge and operational environment.

That means the same architecture can reason about capabilities that are not purely technical:

accounting;
invoicing;
authentication;
business workflows;
enterprise data.

This leads to a broader model:

         AI AGENTS
             │
             ▼
    ┌─────────────────┐
    │  CONTROL TOWER  │
    │                 │
    │ Living Map      │
    │ Circuits        │
    │ Knowledge       │
    │ Memory          │
    │ Policies        │
    │ Decisions       │
    │ Observability   │
    └────────┬────────┘
             │
   ┌─────────┴──────────┐
   ▼                    ▼

Infrastructure Applications
│ │
Azure Odoo

The objective isn't to replace Azure, Odoo, NetBox, Backstage, monitoring platforms or network simulators.

It is to explore what could exist above and between these systems.

A common operational layer.

The question I'm trying to answer

The interesting question for me is no longer:

"How can I give an AI agent access to my infrastructure?"

It is:

"How can humans and AI agents work on the same operational representation of an enterprise?"

A representation that is:

alive;
contextual;
executable;
observable;
auditable;
and eventually replayable.

That is the direction behind the Control Tower.

I don't consider the architecture finished.

I'm interested in the engineering discussion:

Would an operational map that you can actually work on be useful in your environment?

And if it existed, what would you want to be able to do from it?

Et si les agents IA avaient besoin d’une carte vivante de l’entreprise ?

Code Nomi Nomi — Sun, 30 Aug 2026 12:21:15 +0000

fotsopatrick / tour-community

Tour de controle — edition Community (AGPL) : briques libres + agents Chloe et Braignak

Tour de contrôle — édition Community

L'édition Community est publique.

Les briques libres de la tour, installables sur un Odoo standard :

Code source (AGPL) : https://github.com/fotsopatrick/tour-community
Démo en ligne : https://democommunity.matourdecontrole.fr (compte demo / demo)

Ce qu'elle contient (15 briques autonomes) :

Les agents libres : Chloé (chat) et Braignak (observateur), avec votre clé DeepSeek.
Les briques : Actus, Apprentissage, Condense, Cookie Secure, CV, Messages, Nouveautés, Projets, Rappels, Rate Login, Recette, Réponses, Retours, Sauvegardes, Webapps.

Aucune clé API exigée pour installer. Le cœur de la tour (agents complets coffre, circuits, gouvernance) reste une édition séparée, sous licence propriétaire.

La Tour de contrôle (https://matourdecontrole.fr) est une plateforme de pilotage : un tableau de bord, une équipe d'agents, des circuits de validation et des garde-fous. L'édition Community contient des briques autonomes qui s'installent sur un Odoo standard et s'utilisent seules — avec Chloé et Braignak, les deux agents libres.

…

View on GitHub

Les agents IA deviennent capables de lire du code, d'appeler des API, d'exécuter des commandes, de modifier des fichiers et d'enchaîner plusieurs opérations.

Mais une question me semble encore insuffisamment traitée :

Que sait réellement un agent de l'environnement dans lequel il agit ?

Donner à un agent une liste d'outils est une chose.

Lui permettre de comprendre le système derrière ces outils en est une autre.

C'est le problème que j'explore avec un projet personnel que j'appelle La Tour de contrôle.

L'idée

La Tour de contrôle est un prototype de control plane agentique conçu pour se placer entre les agents IA et les systèmes qu'ils peuvent utiliser.

Les agents peuvent être différents :

Claude Code
OpenCode
Gemini
DeepSeek
autres agents

L'idée est qu'ils n'aient pas besoin de porter seuls tout le contexte opérationnel.

La structure ressemble plutôt à ceci :

             AGENTS IA

   Claude Code   OpenCode   Gemini
         \          |        /
          \         |       /
           └────────┴──────┘
                    │
                    ▼
          ┌──────────────────┐
          │ TOUR DE CONTRÔLE │
          ├──────────────────┤
          │ Carte vivante    │
          │ Mémoire          │
          │ Circuits         │
          │ MCP / outils     │
          │ Politiques       │
          │ État             │
          │ Observabilité    │
          └────────┬─────────┘
                   │
                   ▼
            Systèmes réels

La Tour n'a donc pas vocation à remplacer Claude Code ou OpenCode.

Elle cherche plutôt à fournir l'environnement opérationnel dans lequel l'agent peut agir.

La carte vivante

C'est probablement la partie du projet qui m'intéresse le plus.

La Tour possède une représentation graphique de l'environnement, que je compare volontairement à GNS3 ou Packet Tracer.

Mais au lieu de représenter uniquement des équipements réseau, cette carte peut représenter :

agents
services
applications
outils
circuits
dépendances
capacités
états

Dans la version actuelle, la cartographie couvre notamment :

serveurs
conteneurs
volumes
webapps
agents / équipe
outils

et la documentation du système recense notamment 76 webapps et 202 outils dans la carte actuelle.

La carte est alimentée par une découverte de l'environnement et est actuellement rafraîchie périodiquement. Une couche de suivi temps réel est en cours de finalisation.

L'idée n'est donc pas d'avoir un joli diagramme d'architecture.

L'idée est d'avoir une représentation exploitable de l'environnement.

Pourquoi donner une carte à un agent ?

Prenons une demande simple :

« Analyse le problème et lance la procédure appropriée. »

Avec une simple liste d'outils, l'agent doit reconstruire mentalement la structure du système.

Avec une carte, le parcours peut devenir :

Demande
↓
Carte
↓
Capacité pertinente
↓
Circuit
↓
Outil
↓
Action
↓
Résultat
↓
État mis à jour

L'hypothèse derrière cette approche est simple :

Un agent ne devrait peut-être pas seulement savoir quels outils il peut appeler. Il devrait comprendre où ces outils se situent dans l'environnement.

Les circuits

La Tour possède aussi une notion de circuit.

Un circuit représente une procédure opérationnelle réutilisable.

L'idée est d'éviter de demander au modèle de réinventer une procédure déjà connue à chaque exécution.

On peut alors avoir :

Problème
↓
Procédure
↓
Exécution
↓
Vérification
↓
Workflow réutilisable

La logique est donc :

raisonner quand c'est nécessaire, réutiliser une capacité quand elle est déjà connue.

Cette distinction me paraît importante dans des systèmes qui deviennent de plus en plus agentiques.

La mémoire

La mémoire de la Tour ne se limite pas à l'historique d'une conversation.

Le système peut conserver notamment :

connaissances
procédures
expériences
circuits
état opérationnel

Une capacité peut donc suivre une chaîne du type :

Découverte
↓
Apprentissage
↓
Conservation
↓
Récupération
↓
Réutilisation

L'objectif est que l'organisation ne perde pas son savoir opérationnel simplement parce que le modèle ou l'agent change.

MCP comme interface

La Tour expose aussi certaines capacités via MCP.

Dans cette architecture :

Agent
↓
MCP
↓
Tour
↓
outil / circuit
↓
système réel

MCP sert donc d'interface.

La Tour cherche à être la couche qui organise ce qui se trouve derrière cette interface :

contexte
politiques
workflows
état
outils
exécution
observation
Plusieurs agents, un même environnement

C'est une autre hypothèse importante du projet.

J'ai utilisé la Tour avec différents agents et modèles.

Claude Code et OpenCode sont ceux que j'utilise le plus dans mon travail, et j'ai également testé d'autres modèles.

L'observation intéressante est la suivante :

Les agents peuvent changer alors que l'environnement opérationnel reste le même.

Cela conduit à une architecture de ce type :

Claude Code ─┐
OpenCode ────┤
Gemini ──────┤
DeepSeek ────┤
▼
TOUR DE CONTRÔLE
▼
Systèmes réels

Je ne présente pas cela comme un benchmark général des modèles.

C'est simplement ce que j'ai observé sur mon propre environnement.

Le contrôle des actions

Une fois qu'un agent peut agir sur des systèmes réels, une question devient centrale :

Qu'est-ce qu'il a le droit de faire ?

Je ne pense pas qu'un prompt doive être l'unique mécanisme de contrôle.

La logique recherchée est plutôt :

Raisonnement
↓
Capacité demandée
↓
Contrôle / politique
↓
Exécution
↓
Observation

Cela permet d'introduire une séparation entre :

ce que l'agent peut concevoir,

ce que la plateforme lui permet de faire,

et ce qui a réellement été exécuté.

Sécurité

La Tour contient également des composants liés à la sécurité et à la défense opérationnelle.

Parmi les capacités présentes dans la cartographie et les interfaces figurent notamment :

défense réseau
verrouillage d'urgence
veille intrusion
pare-feu

Il existe également des fonctions liées au pentest.

Je préfère cependant être précis : je ne présente pas la Tour comme une plateforme complète de pentest.

Je la présente comme une plateforme qui intègre également des capacités de sécurité et de contrôle opérationnel.

Observabilité

Un autre objectif du projet est de pouvoir observer non seulement le résultat final mais aussi l'exécution.

Le suivi recherché ressemble à ceci :

Quel agent ?
↓
Quel workflow ?
↓
Quel outil ?
↓
Quel système ?
↓
Quel résultat ?
↓
Quel nouvel état ?

Autrement dit :

passer de « l'agent a répondu » à « voici ce que le système a réellement fait ».

La couche de suivi temps réel est actuellement en cours de finalisation.

Ce que la Tour n'est pas

Je préfère être explicite.

La Tour n'est pas :

un nouveau modèle de langage ;
un remplacement de Claude Code ;
un remplacement d'OpenCode ;
un simple chatbot ;
un produit enterprise fini.

C'est aujourd'hui un prototype fonctionnel de control plane pour systèmes agentiques, construit et utilisé dans un environnement réel.

Certaines parties sont avancées.

D'autres sont expérimentales.

Certaines capacités sont testées en production personnelle.

D'autres doivent encore être industrialisées.

Pourquoi ce problème m'intéresse

Les agents deviennent capables de faire de plus en plus de choses :

lire
raisonner
écrire
exécuter
appeler des APIs
modifier des systèmes
enchaîner des opérations

À mesure que leurs capacités augmentent, le problème change.

Il ne s'agit plus seulement de demander :

« Quel agent dois-je utiliser ? »

Mais aussi :

« Dans quel environnement cet agent évolue-t-il ? »

« Que peut-il voir ? »

« Que peut-il exécuter ? »

« Quelle procédure doit-il suivre ? »

« Que s'est-il réellement passé ? »

« Comment retrouver l'état précédent ? »

« Comment changer de modèle sans reconstruire toute l'organisation autour de lui ? »

Cela commence à ressembler à un problème de plateforme, pas seulement à un problème de modèle IA.

Le marché commence lui aussi à traiter ce problème

Je ne prétends évidemment pas avoir inventé cette catégorie.

Microsoft, AWS, IBM, Salesforce, Snowflake, Kong et d'autres travaillent déjà sur des problèmes voisins : gouvernance des agents, orchestration, observabilité, gestion des outils, identité et contrôle.

C'est justement ce qui m'intéresse.

Cela signifie que la question devient moins :

« Les entreprises auront-elles besoin de contrôler leurs agents ? »

et davantage :

« À quoi doit réellement ressembler un control plane agentique ? »

Mon hypothèse actuelle

L'hypothèse derrière la Tour est :

Les agents devraient pouvoir changer, tandis que le contexte opérationnel, les capacités, les workflows, les politiques, l'état et l'observabilité devraient appartenir à une couche indépendante d'un agent ou d'un modèle particulier.

Et peut-être que cette couche doit également fournir quelque chose de plus fondamental :

une carte vivante de l'organisation que les humains et les agents peuvent comprendre et parcourir.

Ce que je cherche à savoir maintenant

Le projet a été construit par itérations, à partir de problèmes réels rencontrés en développant et en opérant le système.

Je cherche maintenant à confronter cette approche à des personnes qui travaillent réellement avec des systèmes complexes.

Pour un CTO ou un responsable plateforme

Est-ce que ce problème existe aujourd'hui dans votre organisation ?

Pour un développeur

Une carte opérationnelle de ce type rendrait-elle réellement vos agents plus utiles ?

Pour un architecte

Où placeriez-vous une telle couche dans une architecture d'entreprise ?

Pour un responsable sécurité

Quels contrôles devraient absolument exister avant de laisser un agent agir sur une infrastructure réelle ?

Pour un responsable produit

Est-ce un vrai problème à résoudre, ou simplement une abstraction intéressante techniquement ?

Et pour ceux qui travaillent déjà avec les agents

Qu'est-ce que je rate ?

Je cherche surtout des critiques concrètes.

La question centrale

Nous sommes en train de construire des agents capables d'agir de plus en plus directement sur nos systèmes.

La prochaine question n'est peut-être plus seulement :

« Comment rendre les agents plus intelligents ? »

Mais :

« Quelle couche doit se trouver entre le raisonnement d'un agent et l'organisation réelle ? »

C'est la question que j'explore avec La Tour de contrôle.

Vos retours sont les bienvenus.

# ALICE — Architectural Reference Document

Code Nomi Nomi — Sun, 30 Aug 2026 07:28:12 +0000

Reference Document — Identity, Architecture and Operating Principles
Reference Version: August 28, 2026

1. Definition of Alice

Alice is a local intelligence system composed of multiple cooperating components.

It is not reducible to its language model.

The Qwen model is one component of Alice. Alice's identity and operational capabilities result from the architecture as a whole:

model + router + memory + map + circuits + tools + learning + execution mechanisms

2. Fundamental Principle

Alice does not have the general objective of becoming “better” at every iteration.

Its principle is:

KNOW → DO → LEARN IF NECESSARY → RETAIN → REUSE

When Alice already knows how to do something, it should be able to use the corresponding knowledge or circuit instead of unnecessarily solving the problem again.

When Alice does not know how to do something and a learning mechanism is available for that task, it can:

discover a solution;
transform it into usable knowledge;
integrate it into its architecture;
reuse it later.

3. Alice ≠ Qwen

Qwen is the language model currently used by Alice.

It provides, among other things:

language understanding;
language generation;
certain reasoning capabilities.

Alice is the complete architecture built around the model.

Alice's overall behavior therefore depends on how the model is combined with:

memory;
the map;
the router;
tools;
circuits;
learning mechanisms.

Principles

Never consider Qwen alone to represent Alice.
Never evaluate Alice's architecture solely according to the model's intrinsic capabilities.
A capability may belong to Alice's architecture without being a native capability of Qwen.

4. Current Architecture

The inspected architecture includes, among other components:

Qwen2.5-3B-Instruct Q4_K_M, served by llama-server on the Alice machine (192.168.1.61), with a context window of 4096;
routeur.py: orchestration layer and routing core;
alicization_adapter.py: teach() interface;
memory.py: SQLite memory for procedures and experiences;
adaptateur_carte.py: interface to the living map;
Living Map: cartes.json, containing knowledge and circuits accessible to the router;
Circuits: reusable operational procedures;
Local tools: memory search, file reading, testing, summarization, system actions, OCR, language registry and care functions;
RL: DonjonSimpleEnv environment and Q-learning for the task of moving toward a target;
Web control interface: dashboard, L0/L1/L2 memory, circuits, observability and tests.

5. Role of the Router

The router is the orchestrator.

It determines which Alice capability should process a request.

The observed flow is, in order:

Query the living map to find a relevant circuit.
Search SQLite memory.
Use OCR when the request involves reading an image.
Detect certain direct system actions.
Use Qwen for more complex actions or the final response.

Principle

The model should not solve a problem again when Alice already has an exploitable procedure for it.

6. Memory and Knowledge

Alice's memory is not merely a log.

It participates in her operational capabilities.

A learned and retained procedure becomes knowledge available for later use.

The inspected state contains, among other elements:

a procedures table;
an experiences table.

A procedure present in the verified state consisted of four operations and had the status VERIFIED.

A retained piece of knowledge should therefore not be considered “erased” simply because it is not present in Qwen's immediate context.

It belongs to Alice's memory architecture.

7. Living Map

The living map is a structured representation of the knowledge and circuits accessible to Alice.

It allows the router to retrieve an already-known capability.

In the tested RL case:

Learning
   ↓
Policy
   ↓
Circuit
   ↓
Living Map
   ↓
Router

A policy produced through learning was transformed into a circuit and then added to the “knowledge” section of the map.

The router subsequently retrieved this circuit when processing a movement request.

8. Circuits

A circuit is a procedure that Alice can execute.

A circuit may originate from a learning process.

Once integrated into the appropriate memory or map, it becomes reusable operational knowledge.

The objective is not necessarily to continuously optimize the circuit.

If the circuit correctly performs the task for which it was learned, it fulfills its purpose.

Principles

A known circuit must be reusable.
A circuit does not need to be replaced simply because another method exists.
A circuit should only be modified based on a justification related to its actual operation, not on a generic architectural preference.

9. Reinforcement Learning

RL is a specialized learning mechanism.

In the environment currently tested, Alice operates on:

a 5 × 5 grid;
four actions:
- up;
- down;
- left;
- right.

Q-learning explores the environment and produces a policy.

This policy can then be exported as a circuit.

The following technical pipeline was successfully tested:

RL Environment
       ↓
   Q-learning
       ↓
     Policy
       ↓
     Circuit
       ↓
  Living Map
       ↓
     Router

The role of RL in this context is therefore not defined as general improvement of Qwen.

RL is used to acquire a procedure for a specific task.

10. What “Learning” Means for Alice

Within this architecture, learning means acquiring an exploitable capability or procedure that was not previously available in Alice's knowledge.

The expected outcome of a learning process is:

Discovery or production of a solution.
Transformation of that solution into an exploitable representation.
Retention in the appropriate memory or map.
Ability to retrieve that knowledge.
Ability to use it later.

Learning does not necessarily require modifying the language model's weights.

11. What Alice Is Not

Alice is not simply Qwen.
Alice is not simply a chatbot with an interface.
Alice is not required to relearn a capability it already possesses.
Alice does not have the intrinsic objective of continuously maximizing a score.
Alice does not need to replace a functional procedure simply because another procedure might be more performant.
Alice should not be rebuilt according to a generic AI-agent architecture without justification from its actual architecture.
Deliberately deleting learned knowledge is not a meaningful test of Alice's ability to reuse that knowledge.

12. Rules for AI Agents Working on Alice

Any AI working on Alice must follow these rules:

Treat this document as the reference definition of Alice.
Inspect the existing architecture before proposing a modification.
Distinguish the language model from the Alice architecture.
Identify the actual role of a component before assigning it a new function.
Do not introduce a feature merely because it is common in agentic systems.
Do not replace existing knowledge without a demonstrated functional reason.
Do not confuse learning, optimization and memorization.
When a capability is declared acquired, verify the complete chain:

Production
    ↓
Retention
    ↓
Retrieval
    ↓
Execution

Report separately:

what is established through execution;
what is inferred from the code;
what remains to be verified.
1. Never declare a mechanism functional based solely on the presence of code: execution and testing are required.

13. Technical State Observed on August 28, 2026

The following elements come from the inspections and tests provided with this document.

They do not constitute a promise of a permanent state.

Machine and Model

Alice machine: 192.168.1.61.
OS and hardware characteristics: the supplied reports contain two contradictory inventories for the host machine; this contradiction must be resolved before documenting the hardware precisely.
Qwen: one report describes Qwen2.5-3B-Instruct Q4_K_M on Alice; another describes Qwen2.5-Coder-1.5B on a separate machine / previous environment. They must not be merged.
On Alice, llama-server is used to serve the local model.

RL

Environment and Q-learning successfully tested after installing Gymnasium in the venv.
RL tests: 4/4 pytest tests passed.
RL → circuit → map → router pipeline: successfully tested.

Memory

SQLite: procedure persisted and readable.

Items Remaining to Verify

Historical /home/orel paths were corrected in the execution report; the final state must be considered the state actually verified on the machine, not an assumption.
Some elements still require independent verification, notably:
- the final consistency of installation scripts;
- the consistency of startup scripts;
- the exact state of the living map before any deployment or open-source operation.

14. Validation Criteria for a New Capability

To declare that Alice genuinely possesses a new capability, the following evidence should be prioritized:

The task was previously unsupported, or no corresponding procedure was available.
The appropriate mechanism produces a solution.
The solution is stored in the intended memory / map representation.
Alice can retrieve that knowledge.
Alice can execute the retrieved procedure.

A quantitative improvement test is necessary only when the actual objective of the feature is optimization.

It should not be imposed as the general definition of learning for Alice.

15. Reference Formula

ALICE =
    MODEL
  + MEMORY
  + MAP
  + ROUTING
  + CIRCUITS
  + TOOLS
  + LEARNING
  + EXECUTION

No single component defines Alice.

Her operational intelligence emerges from the system as a whole and from the interactions between its components.

Reference

ALICE — Architectural Reference Document
Reference Version: August 28, 2026

# ALICE — Document de référence architectural

Code Nomi Nomi — Sun, 30 Aug 2026 07:17:56 +0000

identité, architecture et principes de fonctionnement**

Version de référence : 28 août 2026

1. Définition d’Alice

Alice est un système d’intelligence local composé de plusieurs éléments coopérants.

Elle ne se réduit pas à son modèle de langage.

Le modèle Qwen est une composante d’Alice. L’identité et les capacités opérationnelles d’Alice résultent de l’ensemble de l’architecture :

modèle + routeur + mémoire + carte + circuits + outils + apprentissage + mécanismes d’exécution

2. Principe fondamental

Alice n’a pas pour objectif général de « devenir meilleure » à chaque itération.

Son principe est :

SAVOIR → FAIRE → APPRENDRE SI NÉCESSAIRE → CONSERVER → RÉUTILISER

Lorsqu’Alice sait déjà faire quelque chose, elle doit pouvoir utiliser la connaissance ou le circuit correspondant au lieu de recommencer inutilement le travail.

Lorsqu’elle ne sait pas faire quelque chose et qu’un mécanisme d’apprentissage est prévu pour cette tâche, elle peut :

découvrir une solution ;
la transformer en connaissance exploitable ;
l’intégrer à son architecture ;
la réutiliser ultérieurement.

3. Alice ≠ Qwen

Qwen est le modèle de langage actuellement utilisé par Alice.

Il fournit notamment :

la compréhension du langage ;
la génération de langage ;
certaines capacités de raisonnement.

Alice est l’architecture complète autour du modèle.

Le comportement global d’Alice dépend donc de la façon dont le modèle est combiné avec :

la mémoire ;
la carte ;
le routeur ;
les outils ;
les circuits ;
les mécanismes d’apprentissage.

Principes

Ne jamais considérer Qwen seul comme représentant Alice.
Ne jamais évaluer l’architecture d’Alice uniquement selon les capacités intrinsèques du modèle.
Une capacité peut appartenir à l’architecture d’Alice sans être une capacité native de Qwen.

4. Architecture actuelle

L’architecture inspectée comprend notamment :

Qwen2.5-3B-Instruct Q4_K_M, servi par llama-server sur la machine Alice (192.168.1.61), avec un contexte de 4096 ;
routeur.py : chef d’orchestre et cœur du routage ;
alicization_adapter.py : interface teach() ;
memory.py : mémoire SQLite des procédures et expériences ;
adaptateur_carte.py : accès à la carte vivante ;
Carte vivante : cartes.json, contenant les connaissances et circuits accessibles au routeur ;
Circuits : procédures opérationnelles réutilisables ;
Outils locaux : recherche mémoire, lecture de fichiers, tests, résumé, actions système, OCR, registre de langue et fonctions de care ;
RL : environnement DonjonSimpleEnv et Q-learning pour le cas de déplacement vers une cible ;
Interface web de contrôle : dashboard, mémoire L0/L1/L2, circuits, observabilité et tests.

5. Rôle du routeur

Le routeur est le chef d’orchestre.

Il détermine quelle capacité d’Alice doit traiter une demande.

Le flux observé est, dans l’ordre :

Consultation de la carte vivante pour rechercher un circuit pertinent.
Recherche dans la mémoire SQLite.
Utilisation de l’OCR lorsqu’une demande concerne la lecture d’une image.
Détection de certaines actions système directes.
Utilisation de Qwen pour les actions plus complexes ou la réponse finale.

Principe

Le modèle n’a pas à résoudre de nouveau un problème pour lequel Alice dispose déjà d’une procédure exploitable.

6. Mémoire et connaissance

La mémoire d’Alice n’est pas un simple journal.

Elle participe à ses capacités opérationnelles.

Une procédure apprise et conservée devient une connaissance disponible pour une utilisation ultérieure.

L’état inspecté contient notamment :

une table procedures ;
une table experiences.

Une procédure présente dans l’état vérifié était composée de quatre opérations et avait le statut VERIFIED.

Une connaissance conservée ne doit donc pas être considérée comme « effacée » simplement parce qu’elle n’est pas dans le contexte immédiat de Qwen.

Elle appartient à l’architecture mémoire d’Alice.

7. Carte vivante

La carte vivante constitue une représentation structurée des connaissances et circuits accessibles à Alice.

Elle permet au routeur de retrouver une capacité déjà connue.

Dans le cas RL testé :

Apprentissage
     ↓
Politique
     ↓
Circuit
     ↓
Carte vivante
     ↓
Routeur

Une politique produite par l’apprentissage a été transformée en circuit, puis ajoutée à la zone « connaissances » de la carte.

Le routeur a ensuite retrouvé ce circuit lors d’une requête de déplacement.

8. Circuits

Un circuit est une procédure exploitable par Alice.

Un circuit peut être issu d’un apprentissage.

Une fois intégré à la mémoire ou à la carte appropriée, il constitue une connaissance opérationnelle réutilisable.

Le but n’est pas nécessairement d’optimiser continuellement le circuit.

Si le circuit permet de faire correctement la tâche pour laquelle il a été appris, il remplit son rôle.

Principes

Un circuit connu doit être réutilisable.
Un circuit n’a pas besoin d’être remplacé simplement parce qu’une autre méthode existe.
Une modification d’un circuit doit avoir une justification liée à son fonctionnement réel, pas à une préférence architecturale générique.

9. Apprentissage par renforcement

Le RL est un mécanisme spécialisé d’apprentissage.

Dans l’environnement actuellement testé, Alice dispose :

d’une grille 5 × 5 ;
de quatre actions :
- haut ;
- bas ;
- gauche ;
- droite.

Le Q-learning explore l’environnement et produit une politique.

Cette politique peut ensuite être exportée sous forme de circuit.

Dans les tests réalisés, le pipeline technique suivant a fonctionné :

Environnement RL
       ↓
   Q-learning
       ↓
     Politique
       ↓
     Circuit
       ↓
  Carte vivante
       ↓
     Routeur

La fonction du RL, dans ce contexte, n’est donc pas définie comme une amélioration générale de Qwen.

Le RL sert à acquérir une procédure pour une tâche donnée.

10. Ce que signifie « apprendre » pour Alice

Dans le cadre de cette architecture, apprendre signifie acquérir une capacité ou une procédure exploitable qui n’était pas auparavant disponible dans la connaissance d’Alice.

Le résultat attendu d’un apprentissage est :

Découverte ou production d’une solution.
Transformation de cette solution en représentation exploitable.
Conservation dans la mémoire ou la carte appropriée.
Possibilité de retrouver cette connaissance.
Possibilité de l’utiliser ultérieurement.

Il n’est pas nécessaire que l’apprentissage modifie les poids du modèle de langage.

11. Ce qu’Alice n’est pas

Alice n’est pas simplement Qwen.
Alice n’est pas simplement un chatbot avec une interface.
Alice n’est pas obligée de réapprendre une compétence qu’elle possède déjà.
Alice n’a pas pour objectif intrinsèque de maximiser continuellement un score.
Alice n’a pas besoin de remplacer une procédure fonctionnelle uniquement parce qu’une autre procédure pourrait être plus performante.
Alice ne doit pas être reconstruite selon une architecture générique d’agent IA sans justification par son architecture réelle.
La suppression volontaire d’une connaissance apprise n’est pas un test pertinent de sa capacité à réutiliser cette connaissance.

12. Règles pour les agents IA qui travaillent sur Alice

Toute IA intervenant sur Alice doit respecter les règles suivantes :

Considérer ce document comme la définition de référence d’Alice.
Inspecter l’architecture existante avant de proposer une modification.
Distinguer le modèle de langage de l’architecture Alice.
Identifier le rôle réel d’un composant avant de lui attribuer une nouvelle fonction.
Ne pas introduire une fonctionnalité uniquement parce qu’elle est courante dans les systèmes agentiques.
Ne pas remplacer une connaissance existante sans raison fonctionnelle démontrée.
Ne pas confondre apprentissage, optimisation et mémorisation.
Lorsqu’une capacité est déclarée acquise, vérifier la chaîne complète :

Production
    ↓
Conservation
    ↓
Récupération
    ↓
Utilisation

Rapporter séparément :

ce qui est établi par exécution ;
ce qui est déduit du code ;
ce qui reste à vérifier.
1. Ne jamais déclarer un mécanisme fonctionnel sur la seule présence du code : l’exécution et les tests sont nécessaires.

13. État technique constaté au 28 août 2026

Les éléments suivants proviennent des inspections et tests fournis avec ce document.

Ils ne constituent pas une promesse d’état permanent.

Machine et modèle

Machine Alice : 192.168.1.61.
OS et caractéristiques matérielles : les rapports fournis contiennent deux inventaires contradictoires pour la machine hôte ; cette contradiction doit être résolue avant de documenter précisément le matériel.
Qwen : un rapport décrit Qwen2.5-3B-Instruct Q4_K_M sur Alice ; un autre décrit Qwen2.5-Coder-1.5B sur une machine distincte / ancien environnement. Ils ne doivent pas être fusionnés.
Sur Alice, llama-server est utilisé pour servir le modèle local.

RL

Environnement et Q-learning testés avec succès après installation de Gymnasium dans le venv.
Tests RL : 4/4 tests pytest passés.
Pipeline RL → circuit → carte → routeur : testé avec succès.

Mémoire

SQLite : procédure persistée et lisible.

Points restant à vérifier

Des chemins historiques /home/orel ont été corrigés dans le rapport d’exécution ; l’état final doit être considéré comme celui réellement vérifié sur la machine, pas comme une supposition.
Certains éléments restent à vérifier indépendamment, notamment :
- la cohérence finale des scripts d’installation ;
- la cohérence des scripts de démarrage ;
- l’état exact de la carte vivante avant toute opération de déploiement ou d’open source.

14. Critères de validation d’une nouvelle capacité

Pour déclarer qu’Alice possède réellement une nouvelle capacité, privilégier la preuve suivante :

La tâche était auparavant non couverte ou aucune procédure correspondante n’était disponible.
Le mécanisme approprié produit une solution.
La solution est enregistrée dans la représentation mémoire / carte prévue.
Alice peut retrouver cette connaissance.
Alice peut exécuter la procédure retrouvée.

Un test d’amélioration quantitative n’est nécessaire que si l’objectif de la fonctionnalité est effectivement l’optimisation.

Il ne doit pas être imposé comme définition générale de l’apprentissage d’Alice.

15. Formule de référence

ALICE =
    MODÈLE
  + MÉMOIRE
  + CARTE
  + ROUTAGE
  + CIRCUITS
  + OUTILS
  + APPRENTISSAGE
  + EXÉCUTION

Aucune composante prise isolément ne définit Alice.

Son intelligence opérationnelle résulte de l’ensemble du système et de leurs interactions.

Référence

ALICE — Document de référence architectural
Version de référence : 28 août 2026

Building an Agentic Control Plane: Architecture, Governance and Replayable Workflows

Code Nomi Nomi — Sat, 29 Aug 2026 10:20:03 +0000

AI agent systems are becoming increasingly capable — but operating them reliably is a different problem.

Once a system contains multiple agents, workers, APIs, asynchronous jobs, infrastructure automation and security controls, the main challenge is no longer simply building agents.

It is controlling the system around them.

I built an agentic control plane to explore this problem: a platform designed to give me a single operational layer for orchestrating agents, observing executions, enforcing governance and replaying workflows.

This article explains the architecture and the engineering principles behind it.

The problem: agents are easy to add, difficult to operate

A single AI agent is relatively simple.

Add several agents with different responsibilities, however, and the system quickly becomes more complex:

User
  ↓
Agent A
  ↓
Agent B
  ↓
Worker
  ↓
API
  ↓
Infrastructure

Now introduce asynchronous execution, shared state, authentication, failure handling, observability and security.

The architecture starts looking more like a distributed system than a chatbot.

The question becomes:

How do you operate an agentic system as an engineered platform rather than a collection of independent agents?

That is the problem I wanted to investigate.

From agents to a control plane

Instead of treating every agent as an isolated application, I designed a control layer around them.

The simplified architecture looks like this:

                         ┌─────────────────────┐
                         │       Client        │
                         └──────────┬──────────┘
                                    │
                                    ▼
                         ┌─────────────────────┐
                         │   Control Plane     │
                         │                     │
                         │ Routing             │
                         │ Governance          │
                         │ Execution           │
                         │ Observability       │
                         └──────────┬──────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    │               │               │
                    ▼               ▼               ▼
                 Agents           Worker          Services
                    │               │               │
                    └───────────────┼───────────────┘
                                    │
                                    ▼
                              Infrastructure

The important distinction is that the agents are not the platform.

They are components operated by the platform.

That distinction changes the architecture considerably.

1. Agents become managed components

Each agent has a defined responsibility.

Instead of allowing agents to arbitrarily interact with everything around them, the control plane provides boundaries around execution.

Conceptually:

Agent
 ├── Identity
 ├── Capabilities
 ├── Inputs
 ├── Outputs
 ├── Execution state
 └── Policies

This makes an agent closer to a platform workload than a simple prompt wrapped around an LLM.

The control plane can therefore answer questions such as:

Which agent is running?
What is it allowed to do?
What triggered the execution?
Which workflow is it part of?
What happened during execution?
Did the execution succeed?
Can the execution be reproduced?

These questions become increasingly important as the number of agents grows.

2. Governance is part of the architecture

Governance should not be an afterthought.

An agent that can call an API, modify infrastructure or trigger another workflow effectively has operational capabilities.

Those capabilities need boundaries.

I therefore treat governance as an architectural layer:

                ┌───────────────────┐
                │      Request      │
                └─────────┬─────────┘
                          │
                          ▼
                ┌───────────────────┐
                │     Governance    │
                │                   │
                │ Identity          │
                │ Permissions       │
                │ Policies          │
                │ Validation        │
                └─────────┬─────────┘
                          │
                          ▼
                ┌───────────────────┐
                │     Execution     │
                └───────────────────┘

The objective is not to prevent automation.

It is to make automation controlled and observable.

3. Asynchronous execution

Not every operation should happen synchronously.

Some workflows can take time, involve external systems or require multiple steps.

A worker-based execution model provides a useful separation:

API
 │
 ├── validate request
 │
 ├── create execution
 │
 └── enqueue job
          │
          ▼
        Redis
          │
          ▼
        Worker
          │
          ├── Agent execution
          ├── External API calls
          └── Infrastructure operations

This separates the request lifecycle from the execution lifecycle.

The API can acknowledge the operation while the worker performs the actual workflow.

It also gives the control plane a natural place to track execution state.

For example:

PENDING
   ↓
RUNNING
   ↓
SUCCESS

or:

PENDING
   ↓
RUNNING
   ↓
FAILED

The state itself becomes an operational artifact.

4. Observability

An agentic system cannot be operated effectively if the only observable output is:

"Task completed."

I want to know what actually happened.

For each execution, the platform can associate:

Execution
 ├── workflow
 ├── agent
 ├── timestamp
 ├── input
 ├── state
 ├── events
 ├── logs
 ├── outputs
 └── errors

This creates an execution history rather than a black box.

The control plane becomes a place where the system can be inspected as it operates.

5. Replayable workflows

This is one of the most useful capabilities I added.

If an execution is represented as a structured workflow rather than an ephemeral interaction, it can potentially be replayed.

For example:

Workflow #1842

Step 1 → Agent A
Step 2 → Validation
Step 3 → Agent B
Step 4 → Worker
Step 5 → Infrastructure operation

Instead of simply recording:

Something happened.

The platform records:

This workflow executed these steps, in this order, with these inputs and these results.

That enables another important operation:

Original execution
        │
        ▼
      Record
        │
        ▼
      Replay
        │
        ▼
   Compare results

Replay is particularly interesting for testing.

A workflow that previously failed can become a regression case.

A security scenario can become a repeatable test.

An operational circuit can become something that can be executed again under controlled conditions.

This moves testing closer to the actual behavior of the platform.

6. The control plane as an operational interface

Once the system has structured execution state, workflows, agents and infrastructure events, the next problem becomes visualization.

Instead of exposing every component through separate interfaces, I built a centralized operational interface around the control plane.

The interface provides a representation of the system itself:

                CONTROL PLANE

     ┌──────────┐       ┌──────────┐
     │  Agents  │──────▶│ Workers  │
     └──────────┘       └────┬─────┘
                             │
                             ▼
                       ┌──────────┐
                       │ Services │
                       └────┬─────┘
                            │
                            ▼
                     Infrastructure

The visual layer is not the architecture.

It is a representation of the architecture.

That distinction is important.

The underlying system remains API-driven and service-oriented; the visual interface becomes an operational surface on top of it.

7. Why this architecture matters

The interesting part of an agentic platform is not the number of agents.

It is the operational model around them.

I found four principles particularly important:

1. Agents should be managed as workloads

An agent needs identity, capabilities, state and boundaries.

2. Execution should be observable

A workflow should produce structured execution data, not only a final response.

3. Workflows should be replayable

If an operation matters, being able to reproduce it is extremely valuable for testing and debugging.

4. Governance belongs in the control plane

Permissions, validation and execution policies should surround automation rather than being implemented independently inside every agent.

What I learned

Building this system changed the way I think about agentic applications.

The difficult part is not getting an LLM to call a tool.

The difficult part is building the infrastructure that makes those actions:

controlled,
observable,
testable,
reproducible,
and operationally understandable.

That is why I increasingly think about agentic systems in terms of platform engineering.

An agent is a component.

A workflow is an execution unit.

A worker is an execution engine.

And the control plane is what turns those components into an operable system.

Where this goes next

There are still many areas to explore:

stronger policy enforcement,
richer execution traces,
more deterministic replay,
automated regression testing,
failure injection,
security testing,
and better visualization of distributed agent workflows.

The goal is not to build more agents.

The goal is to make increasingly autonomous systems operable.

That is the problem I am exploring with this project.

What would you put in an agentic control plane?

I am particularly interested in approaches to governance, replayability and testing of multi-agent systems.