// HACKER NEWS — CYBERSECURITY
An Accidental Blackboard
Giles is CTO for Europe, Middle East and India at
Thoughtworks. He has over 25 years experience in engineering and
technology leadership across technologies from mobile to AI and
industries including retail, fintech and
healthcare.
This article is part of “Exploring Gen
AI”. A series capturing Thoughtworks technologists' explorations of using gen ai technology for
software development.
This week, across Thoughtworks Europe, we took 10 engineers and put
them in one room in our Barcelona office. The goal was to see how far
and how fast we could go if we really leant into agentic
engineering. We called it hyper-agentic. Along the way, we
accidentally re-discovered something about coordinating agents.
The 10 engineers were given the goal of building an airline IROps
system. This is the system that airlines use in a flight control
centre when something goes wrong. When a plane has a technical fault
that needs to be repaired. When a crew member gets sick and the crew
needs to be replaced. It’s how they decide which flights to cancel,
which planes to swap, which passengers get offloaded and put into
hotels, etc. etc. They’re doing this over hundreds of aircraft,
hundreds of thousands of passengers and many, many crew across
multiple stations and airports. It’s a really, really hard problem,
hard to solve, hard to execute. An IROps system is complex to build,
complex to understand, and complex to use.
We managed to build one in four days. But this post isn’t about how we
did that.
We started with a specification and a simulated airline, because this
was a practice exercise, not a real client. We tried a couple of
things just to see what would and wouldn’t work. We used a
monorepo. All the engineers began working at once. We just got
started, and after a couple of days we began to see things happening
in interesting ways, things emerging.
With lot of agents working in one repo, build pipelines suffered. To
deal with this we introduced a discipline: our agents were to
continually commit and rebase from main. At first, we required a
rebase after commit and to then push, with all of the build checks and
controls in place. We introduced this change to catch build failures
locally: integrate early and often. But, there was a side-effect. We
were directing the agents to plan, to scope work to sections in the
spec and to create plans linked to those sections. These plans were
stored in the repo. All agents were working off the same spec using
the same numbered and identified sections. As agents worked, plans
were updated to record progress. These updates, alongside all others,
were swept up with the new commit discipline. Agents were able to see
other agents’ progress.
So, one agent was, say, working on the evaluator, the component to
determine if a particular plan to restore operations is valid, whether
it breaks hard constraints or soft constraints, etc. At the same
time another agent was working on the search algorithm that looks for
plans that could solve the disruption. The search component depends on
the evaluator. Each component can be written together, but there is a
shared interface and search depends on the evaluator.
The plans recorded these integration points. One plan said at this
point I’m going to need to update the callers to call the real
verifier. And on the search side, it said, at this point I need to
insert the call to the real verifier when it arrives. Both agents
could see each plan, and the progress. We realised that the agents
were using the plans to coordinate. One agent would mark a line of the
plan as in progress, the other agent would see that and not work on
that line. When the first agent finished, the other agent would see
not only that the work was complete and thus it was released to
proceed, but would also be directly delivered notes on how the line
had been implemented.
We started to exploit this. We’d kick off a session and direct it to
work on a particular journey. One example