DEV Community: Code Nomi Nomi

# 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.