Brand Portal RFP Criteria for Multi-Brand Companies
AI agents now need direct access to structured brand data, not human-readable guidelines in a PDF.
Multi-brand companies and agencies are producing content at a pace and volume no human review cycle was built to handle, and that single fact breaks the logic every brand portal RFP has relied on for years. The old test asked whether a portal could centralize brand assets for people to find. The test that matters now is whether a portal can serve as structured, machine-readable infrastructure that an AI agent can draw from directly.
A brand portal built in the last decade assumed a predictable chain of events: a designer logs in, opens the guidelines, reads them, and applies judgment before anything goes out the door. That chain had a human at every link. It is the reason portals were scored on things like how cleanly they displayed a logo lockup or how easy it was to browse a color palette by eye.
That chain no longer describes how most brand work gets done. When an AI agent is writing the copy, generating the image, or producing the fortieth social variant of a single campaign, the agent is the one that needs to apply the guidelines, not a person reviewing them afterward. And an agent cannot read a 60-page PDF the way a designer can. The shortfall here has nothing to do with whether AI tools are capable of good creative work. It has to do with whether the AI has proper brand context available to draw from. A model with no structured brand data behaves exactly as you'd expect: it guesses, and the guesses drift.
That shift changes the central question an RFP has to answer. The old question, "does this portal centralize our brand assets," no longer tells a buyer anything about whether the system will hold up under AI-driven production. The question that replaces it is whether the portal can function as structured, machine-readable brand infrastructure, and every criterion that follows in this piece exists to answer that one question in detail.
What an RFP written for human-only portals misses
Most brand portal RFPs still run on a checklist built for human users: centralized file storage, version control on assets, access permissions by role, search, and a clean interface for browsing the guidelines. A portal can score well on every one of those items and still be unusable to any AI tool the team actually works with.
A portal can present beautifully organized, well-designed brand guidelines built entirely for a person to read, and it can still produce nothing an agent can query.
The same failure appears in event RFPs. Brand portal RFPs make the same mistake in a different form: they spell out file formats, folder structures, and who has edit access, without ever specifying how the portal exposes brand context to a non-human consumer.
The cost of that omission compounds daily. Every new AI session starts from nothing, because the system has no persistent brand context to hand the agent. Every team member ends up manually pasting guidelines into prompts, copy-pasted from a PDF or a wiki page. None of this is a hypothetical cost. It is the daily tax a human-only portal imposes the moment AI tools enter the workflow, and it only grows as output volume grows.
The foundational criterion: whether brand guidelines are machine-readable at all
The first and most basic question any brand portal RFP should ask is whether the system can expose brand guidelines in a form an AI agent can consume directly, not a form a human has to read and then retype into a prompt. This single question separates portals that will function under AI-driven workflows from portals that will quietly become shelfware the moment a team adopts agentic tools.
Machine-readability comes in tiers, and the RFP should name the specific tier it requires. A structured file, something in JSON or YAML or an equivalent format that encodes brand tokens like colors, fonts, and spacing rules, is a meaningful step up from a PDF. But it still requires an agent, or a person operating one, to go find that file and parse it manually before each use. A live endpoint, a URL or an API that always returns the current brand context on request, is more dependable because it can't drift out of sync with the brand the way a file sitting on someone's desktop can. It always reflects what's true now, not what was true when the file was last downloaded.
What that machine-readable data needs to actually contain is more detailed than most RFPs spell out. A color isn't just a hex code. Voice and tone can't be summarized as "modern and fresh," because that phrase gives an agent nothing to act on. It needs to come down to actual rules: what to write, what to never write, which sentence patterns read as on-brand and which don't.
Vendors should be asked to prove this with a live demonstration, not a slide. Hand them a brand and ask what the machine-readable export actually looks like, then check whether it can be pulled into the team's existing AI tools without a custom development project standing between the portal and the tool doing the work.
Why MCP support is now a non-negotiable portal requirement
If a portal produces machine-readable brand data but still needs a custom integration for every AI tool a team touches, it hasn't solved the underlying problem. It has just moved that problem one layer down, from "the data isn't structured" to "the data is structured but trapped behind a one-off connector for each tool."
MCP closes that gap by giving systems a standard interface that replaces a pile of bespoke connections. Building one MCP connection to a portal lets any MCP-compatible agent pull brand context from it, whether that agent runs inside Claude, Cursor, ChatGPT, or any other environment that speaks the same protocol. By December 2025, MCP had been adopted across the major AI platforms, and it was donated to the Linux Foundation's Agentic AI Foundation (AAIF) as a vendor-neutral, community-governed standard. That matters for a buyer evaluating portals today because MCP support is no longer a bet on one company's roadmap. It's alignment with the interface the rest of the industry has already settled on for how agents talk to outside systems.
For a company or agency running multiple brands, MCP support should deliver a few concrete things. Brand context should also function as shared infrastructure for the whole team, so no individual user has to configure it on their own machine.
Its official MCP server works within the platform's existing roles and permissions rather than bypassing them, it logs every change an agent makes in the site's activity log, and it lets each site define its own Agent Instructions, site-specific rules the agent follows that can include brand and design-system conventions. That's a working example of a permissions-aware, logged, instructable agent connection, and it's the bar portal vendors should be measured against.
An RFP should ask, point blank, whether the vendor has a documented MCP server, whether that server is officially maintained by the vendor or cobbled together by a third party, and what permissions model governs what an agent is allowed to touch once it's connected.
Security and governance requirements that MCP adoption makes mandatory
Opening brand context to AI agents through a live protocol creates a real attack surface if the portal hasn't built the right controls around it, and a lot of vendors haven't. Treat this the way any IT team would treat a new system handling sensitive business data: ask for documentation, not assurances.
An RFP needs a documented answer to at least three things. First, OAuth 2.1 support for authenticated agent access. Second, audit trails: every time an agent reads or writes brand data, that action needs to be logged in enough detail to reconstruct what happened and why, after the fact. Third, protection against command injection: the vendor should be able to document how its MCP implementation defends against prompt-injection and tool-poisoning attacks, both of which are known risks in any system that lets an outside agent issue instructions.
For agencies and multi-brand operators specifically, governance also has to extend to client isolation. If a vendor can't document controls across these points, it isn't a viable option, no matter how impressive its machine-readability or MCP story looks on a slide. Security here is the floor every vendor has to clear, not a feature that separates the good vendors from the great ones.
Multi-brand structure requirements: isolation, inheritance, and rollup
A portal designed around a single brand, handed to a team running a dozen brands or client accounts, recreates the same consistency failure at the portfolio level that a weak portal creates at the single-brand level. Context bleeds between brands, standards drift apart without anyone noticing right away, and the team ends up spending its time catching inconsistencies instead of producing work. This is where the evaluation shifts from whether a portal can serve an AI agent at all to whether it can serve a team managing many brands, often for many different clients, at the same time.
An RFP should make vendors walk through three distinct structural capabilities. Brand isolation means each brand in the workspace has its own context, its own asset library, its own voice rules, and its own permission set, so that an agent working on Brand A has no path to Brand B's context, and a client user assigned to one brand can't see another client's assets. Template and prompt inheritance means reusable structures, like prompt groups, report layouts, or workflow templates, can be built once at the portfolio level and cloned per brand without manual duplication, with brand-level copies inheriting updates from the base template automatically. Portfolio rollup means agency leads and multi-brand operators can see across the whole portfolio at once, without opening each brand's workspace individually, to spot which brands are producing consistent output, which are drifting, and which have brand context that's gone stale.
What each role can see, what it can change, and what needs a separate approval step before it ships are three different questions, and a portal's permission model needs to answer all three.
A useful test for any vendor demonstration: walk through a rebrand on one client account that changes its color palette and voice rules, and ask how the system propagates that change, and what happens to AI-generated content that's already in flight and was built using the old context.
Evaluating whether a portal can keep AI-generated creative on-brand over time
The failure that breaks most AI-generated creative programs is the tenth piece of output, produced three months later, after the brand has evolved and the guidelines have been updated somewhere, but the portal's machine-readable layer never caught up.
A PDF or a static design-system page only captures a brand's decisions at the moment someone published it. An AI agent has no way to reach any of that accumulated knowledge if the portal never stored it in a form the agent can query, and the output regresses toward generic, safe, forgettable work as a direct result.
An RFP should evaluate brand context as something that has to keep working over time, not just something that works on day one. And the strongest systems let a team feed performance data and creative feedback back into the brand context layer itself, so the system reflects what on-brand output actually performs well, not just what the written guidelines predicted it should look like.
A direct test for any vendor: if a global color palette changes today, which AI sessions tomorrow reflect that change, and which don't? Bloom's approach to this problem treats brand context as a versioned Brand Skill, updated once at the source and available for any connected agent or product to retrieve the next time it runs a task, so the team isn't stuck manually redistributing updates every time the brand changes.
The RFP scoring framework: how to weight these criteria in practice
Everything covered above sorts into two tiers, and an RFP scoring framework should treat them differently rather than averaging them together into a single score.
The first tier is threshold criteria, evaluated pass or fail. A vendor needs a machine-readable brand context export, an MCP server with documented OAuth 2.1 support, audit trails paired with approval-gate controls, and per-brand isolation in any multi-brand workspace. A vendor missing any one of these four shouldn't move forward to scored evaluation at all, regardless of how strong the rest of its pitch is.
The second tier is differentiating criteria, the items that separate a good vendor from a great one once the threshold is cleared.
None of this should be taken on a vendor's word. The RFP should require a live sample export of a real brand's machine-readable context, pulled into one of the team's own AI tools during the evaluation itself, and a walkthrough of an actual brand update propagating into an active agent session, showing the before and after state in real time. A portal that can show both of those working in real time has already answered the only question that matters: whether it functions as brand infrastructure an agent can use, not just a library a person can browse.
