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

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:

1. Observe

Understand what is currently happening.

1. Replay

Reconstruct a previous execution or incident.

1. Simulate

Test a potential change without immediately affecting production.

1. Decide

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

1. Execute

Apply the approved or automatically permitted action.

1. 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?