In 2023, generative AI had arrived in public consciousness but almost nowhere in enterprise operating models. Most organisations were looking at it as a novelty — a chatbot on a website, a writing tool for the marketing team — rather than as something that could change how the business itself ran.

The engagement was a bid to a large retail property operator: a shopping centre business with tenants, consumers, internal staff, marketing, leasing, operations and customer service all generating and needing information. The question was not whether AI could answer questions. It was what an AI-enabled version of that whole operation would look like.

The proposal opened with the case for acting rather than waiting, built on published research rather than assertion: Goldman Sachs projecting generative AI could lift global GDP by around 7% and productivity by around 1.5%, and McKinsey's finding on time spent retrieving information.

The argument was deliberately structured around four business outcomes rather than four technologies — accurate forecasting, operational efficiency, cost reduction, and IT and digital security. Each was then mapped down to specific capabilities, so the proposal read as a business case with an AI implementation rather than an AI pitch looking for a justification.

I worked as a Business Analyst on the bid team, contributing the enterprise AI capability framework, the platform concept and the supporting analysis that connected AI capability to business value.

The analytical work was structuring: taking a broad and fashionable technology and decomposing it into named capabilities, mapped to named business functions, each with an articulated mechanism and value. That decomposition is what turned a general enthusiasm for AI into something a client could evaluate, price and decide on.

MART is the organising idea of the proposal. Rather than presenting a list of features, it groups AI capability into four modes of assistance — because the question a business actually asks is not "what can the model do?" but "what kind of help am I asking for right now?"

Each mode has a distinct input, a distinct output and a distinct owner inside the organisation, which is what makes it a framework rather than an acronym.

Every interaction flow in the proposal follows the same shape: extract the key terms from what the user asked, match them against the organisation's internal database, then generate a response grounded in what came back. External web sources and the model's own knowledge are layered on top, never used in place of the internal record.

That pattern is retrieval-augmented generation, designed in 2023 before the term was in common enterprise use. It is also the part of the proposal that has aged best — grounding a general model in proprietary data is now the standard architecture for exactly this class of product, and it was the right answer to the "a public model does not know our business" problem.

The proposal argued value in the terms the client would be measured on: customer satisfaction from always-available service and faster in-centre navigation; internal efficiency from automated analysis, summarisation and repetitive production; and external effectiveness from faster, better-targeted marketing.

The comparison slides made the argument concrete by contrasting the existing path — many steps, long cycles, multiple departments, high coordination cost and variable output — against the proposed one. That framing is the reason the proposal reads as operating-model change rather than tool adoption.

The most useful discipline in this project was refusing to lead with the technology. Structuring the whole proposal around four business outcomes, and only then mapping capabilities underneath them, forced every feature to answer "what does this change about how the business runs?" A number of genuinely impressive capabilities did not survive that question.

MART was the same instinct applied to communication. Four modes of assistance is a structure a client executive can hold in their head and use to interrogate a proposal; a list of nineteen features is not. Choosing a framework people can argue with beats presenting a catalogue people politely accept.

It also holds up technically better than I expected. The grounding pattern designed here — extract intent, retrieve from internal data, generate from what came back — is the architecture I now use routinely in AI product work. The 2023 version was reasoned from first principles about what the model did not know.

Two things have changed since. The capability side has become easier — retrieval, tool use, image understanding and structured output are now standard rather than speculative, so much of what the proposal described as achievable is now straightforward to build.

The hard part has moved. What decides whether an enterprise assistant is useful is no longer model capability but knowledge architecture: whether the organisation's information is retrievable, current and trustworthy enough to ground answers in. The proposal treated the internal database as a given. Doing this work now, that assumption would be the first thing I examined.