Meet your model's new mechanic: an AI agent

Fifteen-plus years of TM1 taught me what makes a complicated financial model survive its builder. It turns out the same principles decide whether an LLM can understand your model, and whether an AI agent can maintain it without wrecking it.

I’ve spent most of my career building and rescuing complicated TM1 models: group consolidations, driver-based P&Ls and balance sheets, inter-company elims, allocations, FX, the lot. For years, the payoff for good design was human: the next developer could find their way around, the business trusted the numbers, changes didn’t take a quarter.

That reward just got much bigger. If your model follows the principles below, any major LLM can read it, explain it and, increasingly, update it, with a human still authorising every change. If it doesn’t, no amount of prompting will save you. An AI agent inherits your model exactly as it is: your hidden rules, your hard-coded mappings, your “temporary” fixes from 2019. Poorly implemented and convoluted model logic will lead to more “hallucinations”.

So here they are. Nothing exotic, just the things that separate models that last from models that don’t. All of them lead to customer satisfaction.

1. Constantly innovate — copying an old model is not a design

Building a planning and reporting system shouldn’t be boring, repetitive coding, least of all in the age of AI. On an existing system, look for genuine improvements: enable parallel processing where the workload justifies it, strip out hard-coded logic so updates become dynamic and standardised, or redesign a module that everyone is struggling with. On a new build, resist the temptation to clone a previous model and skip the requirements phase. Re-use can be sensible for generic components. On the other hand, doing it blindly produces a one-size-fits-all system the end users never asked for. An AI agent asked to extend it will faithfully replicate design decisions that were wrong for the client on day one.

2. Challenge the requirements before you build

If you’ve been asked to automate a process that’s broken or inefficient, say so at the analysis phase, not after go-live. Automating a bad process just makes bad output arrive faster. Your job as a model developer shouldn’t be to just follow the initial requirements. Your goal should be to spot any inefficiencies and, wherever possible, propose an improved design. That’s where the real value sits for the customer, and it’s a judgment call no agent will make for you. The requirements you sign off become the specification every future maintainer, human or AI, treats as truth.

3. Less is more

TM1 gives developers enormous freedom and imposes relatively few limits on how a model is designed. That freedom could easily turn into a developer trap. Every clever extra cube, every custom rule and feeder, every lookup dimension and subset, every bespoke Turbo Integrator process is another thing someone must understand before they can safely touch anything.

Think of the electric motor: it delivers the same torque as a combustion engine but with a fraction of the moving parts. Less to break, less to service, less to explain.

A model with fewer, cleaner components isn’t a less capable model. It’s a model where the failure modes are countable. And an LLM’s comprehension degrades the same way a human’s does: the more sprawling and idiosyncratic the design, the shakier its mental map of it.

4. Design for the change you haven’t been asked for yet

A financial model is a living, breathing creature, absurd as that sounds. New accounts will appear. Country, segment and product/SKU hierarchies will be reshuffled. Rules will change. Someone will want a new FX scenario the week before board pack. Implementing change should be a built-in feature of the model, not an event that requires a developer and a change window. If adding an account means editing rules in six places, you haven’t built a model, you’ve built a maintenance burden.

Take an ordinary example: the business acquires a company with a different chart of accounts, a different reporting currency and its own product hierarchy. A well-designed model absorbs the new entity through mappings, hierarchies and scenario settings; a brittle one requires rules and reports to be rewritten.

5. Self-service is the norm, not the reward

This is the operational twin of principle 4. Users making curated, controlled updates themselves (mappings, hierarchies, scenario assumptions) is what unleashes a reporting model’s full potential. If every change is stone-walled behind an IT approvals process or a technology constraint (hard-coded rule logic instead of a dynamic lookup module), the business loses confidence in the system no matter how fast and accurate it is.

And here’s the AI angle: the structures that enable safe human self-service (lookups, parameter cubes, validated inputs) are exactly the structures that let an agent make safe changes too. Curated self-service for humans and for agents is the same engineering problem.

6. Think and design modular

A good FP&A system works as an ecosystem of tightly connected but separable services: a loader, a validation engine, a mapping engine, an FX rates module, a reporting layer.

Modularity buys you three things. Auditability: each component can be reviewed in isolation. Portability: a well-built mapping engine can be lifted into the next system. And, increasingly, agent-compatibility: an AI can reason reliably about one component with clear inputs and outputs, where it would struggle in a monolith whose parts all depend on each other.

7. No hard-coding, no hidden rules

Obvious to anyone in the field, ignored constantly under deadline pressure. The quick fix (the element name embedded in a rule, the magic constant in a TI process, the exception nobody documented) always comes back to haunt you, usually years later and usually in month-end week. For an AI maintainer, hidden logic is worse than technical debt: it’s invisible. An agent will confidently modify a rule without knowing about the undocumented exception buried three processes away, and the model will be wrong in a way nobody notices until the numbers are published. If logic isn’t discoverable by reading the model, it effectively doesn’t exist until the day it breaks something.

8. Never build in isolation

A model should always be open for other systems, and now other agents, to send it inputs and receive its outputs, in real time or close to it. Provide alternative connectivity routes: flat files for the pragmatic cases, REST APIs for the modern ones. Keep every route thin and governed: they should all pass through the same validation and mapping modules, so an extra interface never means duplicated logic or an unmanaged back door.

A connected model becomes a key enabler in the broader organisation; an isolated one becomes an island that someone eventually decides to decommission. In an agent-driven stack this matters even more: an agent can only orchestrate what it can reach.

9. Have fun

Finally, enjoy the work. Designing an FP&A model doesn’t need to be a dull exercise. With AI getting smarter with each day, the limits on what one developer can deliver are falling away. The tedious parts can increasingly be handed over; the design judgment, the process challenge and the search for a simpler solution stay with you. That’s always been the fun bit anyway.

The common thread

Every one of these principles was written for human maintainers, and every one now doubles as an AI-readiness checklist. Simple, modular, explicit, connected, changeable: that’s what makes a model understandable. And a model an LLM can understand is a model an agent can maintain. The ones it can’t understand will stay dependent on the one person who still remembers how they work.