Why TravelTech teams need AI control planes, not just AI tools

I’m sharing CitizenPlane’s journey with AI, as an example of how AI can be used in travel tech to make processes easier and improve productivity.

AI usage at work rarely goes beyond a chat window open on the side, with a question typed in, an answer copied out. Although it works and helps in many cases, it stays disconnected from the systems around it.

At CitizenPlane, we made a different choice. We built Claudy, our internal AI control plane for software delivery. This series is an account of what we did, why it is structured the way it is, and what it changed for our team.

The difference between AI as a tool and AI in a working environment

An isolated AI tool is useful the way a good search engine is useful. You bring it a question, it returns an answer. The quality of that answer depends entirely on what you put in: your question, your context, your ability to frame the problem correctly.

The problem is that most real work does not arrive as a clean question. It follows a service that stopped for no reason, a ticket with incomplete context, a branch that conflicts with someone else's changes, a bug that only reproduces in production. Assembling the right context to even ask the right question takes time. And that time spent fetching, switching tools, and reconstructing the situation is where most of the friction lives. AI becomes significantly more useful when it already has that context.

What an AI control plane is

A control plane is the layer from which a team can see, coordinate, and operate a complex system. The concept comes from network engineering, where the control plane manages routing decisions while the data plane handles the actual traffic. Applied to software delivery, it is the layer that connects your services, your repositories, your tickets, your logs, and your people into one coherent picture.

Without that layer, tools stay siloed. Decisions get made with incomplete information. With that layer, AI has something to work with. It can see which service is running which version, which ticket is linked to which branch, which rules apply to which workflow. It does not need to be told every time. The environment carries the context.

Three things make AI work well inside a team environment: context (what is the current state of the system and the work), structure (how do actions, workflows, and information connect to each other), and guardrails (where should AI act autonomously, and where should a person stay in control). A control plane is how you give AI all three from the start of every session.

How this applies in TravelTech specifically

TravelTech is a useful place to think about this because the operating environment is genuinely complex. An airline's stack is not a single application: reservation systems, inventory management, departure control, distribution channels, and revenue management all run simultaneously and exchange data in real time. A booking made through an OTA has to be reflected instantly in the inventory system, which updates the departure control system, which connects to ground handling. A pricing decision in the revenue management layer propagates through fare classes before the next search result appears.

CitizenPlane builds inside that environment. Our software connects to live airline systems, serves real traffic, and has to stay consistent with what is happening in production. The teams building it face the same coordination problem at the development level: multiple services, multiple developers, shared systems. Context is not optional. It is the condition under which the work makes sense at all.

Claudy in practice

At CitizenPlane, we called this control plane Claudy. Claudy brings together technical supervision, active development work, shared knowledge, repeatable workflows, and AI assistance inside the same operating environment.

Each developer works in an independent Claudy environment: their own virtual machine, their own running services, their own AI session with access to their branch, their logs, and their tickets. A Supervisor layer coordinates shared updates, settings, and knowledge across all instances. A shared vault stores rules, notes, and accumulated lessons that persist beyond any single conversation.

In practice, this means a developer debugging a service is not starting from a blank context. Claudy already knows the state of the stack, the recent changes, the relevant tickets. The AI does not need to be briefed from scratch as it is already inside the work.

That is the core idea this series explores: not AI as a separate experiment running alongside real work, but AI embedded inside the environment where the work actually happens.

The next episode covers how Claudy started, which was not as an AI project at all.

This article is the foundation for the rest of the series. In the next pieces, we will explain how Claudy started, how it became part of our day-to-day technical work, and why that matters for TravelTech teams facing growing complexity of their own.

‍