Where TransformRadar is going — from synthesis to agents that govern the work
Thomas Thejn7 min readUpdated 19 September 2026
TransformRadar's AI today synthesises a project's record into drafts. The next step is agents that act on it: chasing task owners for status and proposing the delivery RAG, tracing a Programme Health drop to the slipped tasks and open risks behind it, and coordinating with external agents over MCP. Every action still lands as a preview a person confirms.
The first post in this series argued that project tools are moving from systems of record to systems of action. The second set out what TransformRadar's AI does today. This one is about the distance between the two, and how we intend to close it.
A word on what this post is. It describes direction and the order we expect to work in. It does not carry dates, because every roadmap with dates on it is a work of fiction with a Gantt chart, and the roadmap changes when customers teach us something. Everything described as shipped is shipped. Everything described as next is intent.
From centralising the record to governing the transformation
TransformRadar exists because IT and digital transformation programmes arrive late, diluted, or unmeasured, and because the governance that should have caught it was spread across five tools and rebuilt by hand every month by someone who had other plans for that evening. The first job was to put the record in one place: the plan, the delivery backlog, the governance log, the status, the health assessment, and the value trajectory, on one footing for every project a CIO runs.
The AI layer's first job was to read that record and draft from it. That is where the product is now, and it removes a real amount of assembly work. But assembly was never the hard part of governance. The hard part is noticing in time, and acting. Filing cabinets do not notice. Neither, it turns out, do very good summarisers.
That is the agentic leap: from a workspace that centralises governance data to one that actively governs the transformation. Three capabilities define it.
Status orchestration: the agent chases, the lead confirms
Today a project manager spends the first half of every week collecting status. Messages to task owners. Reminders. A check of whether the dependency actually landed or was merely announced. Then the RAG is typed in from what came back, with a small adjustment for the team lead who is always "on track" and the one who is always "slightly behind" and has never once been slightly behind.
The intended agent does the collection. It asks each task owner for an update on the items due, in the channel they already use. It checks the answers against the plan: a task reported done whose successor has not started, a dependency claimed complete that the delivery backlog shows still in review. It then proposes the delivery RAG, with the evidence attached, and puts it in front of the lead as a preview.
The lead confirms in one action, or edits, or rejects. That step stays. An agent that quietly set a programme's status would be worse than no agent, because the steering group could no longer trust that a person had stood behind the number. What changes is that the lead's Monday morning starts from a proposal with the chasing already done, which is the best Monday morning a project manager has had since Mondays were invented.
The seed of this already exists. My work today lists recommended actions across plan, governance, value, steering, and health, and the Monday digest puts them in the inbox. The step from there to an agent that gathers the inputs itself is a real one, but it starts from a record that already knows what to ask about.
Root-cause tracing: from a score to a story
A Programme Health score is a leading indicator: it moves before the RAG does. What it does not do today, on its own, is explain itself. When governance drops from 74 to 61, someone has to go and find out why, and that someone usually finds out in the steering meeting, from the person who caused it.
The intended agent does the tracing. When a health dimension falls, it links the movement to what changed in the record: the tasks that slipped on the critical path, the risk that has been open without an owner for five weeks, the benefit whose trajectory went amber, the decision that has waited for three steering meetings and is starting to look comfortable there. It assembles that into a narrative with each claim tied to the item behind it, and puts it in the steering pack before the meeting rather than leaving the committee to do archaeology in the room.
This is where the grounding rule pays for itself. A model allowed to invent could write a plausible narrative for any score movement; it would be fluent, confident and occasionally fictional. A model that may only cite the record has to find the actual causes, and if it cannot, it says so. That is a feature. A health drop with no traceable cause in the record is itself a governance finding: something is happening that nobody has written down, and someone should go and ask.
Agents that talk to other agents
The third capability is interoperability at the agent level. The MCP surface today lets an external agent read the governance record and prepare changes to it. The next step runs the other way as well: TransformRadar's own agents asking questions of other systems' agents.
The obvious case is finance. A budget variance in a status report should be verifiable against the ERP without a person exporting a ledger at 11 p.m. and reformatting the dates. A governance agent that can ask the finance system's agent for the actuals against the programme's cost centre, and attach the answer to the status draft, removes a week from the reporting cycle and an entire genre of argument from the steering meeting.
The same discipline applies. Any write that results still lands as a preview a person confirms. What the agent gains is the ability to gather evidence across system boundaries. What it does not gain is the authority to act on it alone.
What will not change
Three rules hold across all of this, and they are the reason the agentic version of TransformRadar can be trusted with more, not less.
- It reframes your data. It does not invent. Every claim an agent makes
traces to an item in the record. This does not relax as agents become more capable; it becomes more important, in the way that brakes become more important as the car gets faster.
- A person confirms every write. Agents gather, analyse, propose, and
draft. The confirmation step is owned by the product interface, not by the model, and no surface, internal or external, gets a route around it.
- One action layer. An agent reaches exactly the capabilities a person
with the same role could reach through the interface, and every mutation records which surface made it. AI never gets a privileged path.
Why where the model runs now matters more
Agentic AI needs deep access. An agent that chases status, traces causes, and queries the finance system is reading the most sensitive description of a business that exists: what it is trying to change, where it is failing, and what that costs. That turns a question that used to live in a procurement questionnaire into a product question. Where does the inference run, who operates it, and do they train on what they see?
TransformRadar's answer is structural rather than a setting. Hosting and the database are on Clever Cloud in Paris, inference runs on Mistral's platform in Paris, and no provider in the chain trains on customer data or is subject to a US disclosure order. As agents get more capable, that chain is what lets a European CIO give them real access. The EU hosting page sets out the full arrangement.
The reason we built it that way was never compliance for its own sake. It is that Europe has to move faster, and IT and digital transformation is where that is won or lost. Governance that shows early whether a bet is working is what makes a bigger bet possible. Agents that do the noticing and the chasing, on infrastructure a European board can trust with its most sensitive record, are the next step in the same argument.
How we will get there
The order of work follows the risk. Proactive monitoring comes first, because it extends what recommended actions already do and every output is a suggestion. Root-cause tracing comes next, because it is synthesis with better evidence, and the steering pack already has the section for it. Status orchestration follows, because it introduces agents that contact people, and agents that contact people need to be taught manners. Agent- to-agent interoperability comes last, because it depends on the other side existing.
None of it requires a new permission model, a new data path, or a relaxation of the confirmation step. That is the point of having built the boring parts first. If you want to see them working today, start with one project and ask Blip what is overdue. It will tell you, and it will not make anything up to be helpful.
- AI
- agentic AI
- roadmap
- EU hosting
- governance