Most companies that sell through partners end up with a portal. Partners need somewhere to register deals, place orders and see what their customers own. Customers need somewhere to renew, get help and learn the product. Over time the portal becomes the front door to systems that live somewhere else: the ERP, the CRM, the support desk.
For most of the last decade, the sensible way to get one has been to buy a portal product, or a CRM's community add-on, and configure it. For plenty of companies that's still the right call.
Two things are changing the calculation.
The first is who shows up. More of the work people do in a portal will soon be done by agents acting for them: a partner's agent checking an order for a customer, a customer's agent asking what next year's renewal will cost. The second is what those agents need. An agent can only work inside a system that lets it in, with access scoped to what it was given and rules it can read, and platforms a company doesn't own often don't grant that kind of access.
So the question worth asking is what a portal has to be when some of its visitors are agents, and who should own it.
Our short answer: treat the portal as a delegation layer. Get identity and permissions right first, keep systems of record in charge, write the rules down where people and agents can both follow them, and own the whole thing so it can change as the traffic does.
Portals were always about delegation
Look at what a partner portal actually does, and most of it is delegation. A partner acts for a customer. A customer's admin acts for their organization, adding colleagues and deciding what each of them can see. A sales rep steps in when a deal is too big for self-service. The portal's real job is keeping track of who is acting for whom, and what each of them is allowed to do.
An agent is one more link in that chain. It acts for a person, who acts for an organization, which may be served by a partner. If the portal's identity model already understands delegation, an agent fits into it. If identity is a login screen in front of a catalog, an agent is either locked out or handed far more access than anyone meant to give it.
The identity and permission model is the product. Everything else in the portal sits on top of it.
What changes when the visitor is an agent
None of what follows is unexpected. It's the discipline a good portal already needs, applied more strictly because the visitor often can't stop to ask a clarifying question.
Actions become interfaces. People click through screens, and agents can call functions. Every action a portal offers (place an order, renew, ask for help, invite a colleague) needs to exist as a well-described, permissioned interface that runs the same rules a person would hit. Otherwise agents end up scraping screens, and a redesign can break them.
Rules have to be written down. A lot of portal logic lives in people's heads: which price applies, which partner gets credit, when a deal needs a person. An agent can only follow rules it can read. When we built DesignDrive for TOM Design Collective, the situations the firm dealt with every week, like returns and change orders, were modeled inside the system rather than handled through workarounds and side spreadsheets. A portal needs the same move, and agents make it much harder to skip.
Every step needs a name on it. When an agent places an order, the record has to say which agent, acting for which person, under which permission. That's what lets someone on your team review what happened, and it's what makes it safe to let agents take on more over time. The decisions that need judgment still go to a person, with the agent's work in front of them.
Why ownership matters more for a portal
We think of sovereignty as owning your data, your infrastructure and your AI stack rather than depending on vendors for them. Portals are one of the clearest cases for it, for three reasons.
The rules are your business. Pricing, attribution, partner tiers and approval thresholds are how you sell. A packaged portal asks you to fit them to its defaults, and each adjustment is a small concession about how your channel works.
Agents need access you can actually grant. To let an agent act inside your portal, you need control over the data and functions it touches. When the portal belongs to a vendor, that access is whatever their roadmap allows.
Release cycles. On someone else's platform, you migrate to features other customers asked for, sometimes at the cost of the customizations you built. Once a platform is built agentically, there's little value in riding a vendor's release cycle.
That's why we use an open source model: it keeps our clients out of vendor contracts that might not serve them in the long term, or that gate or limit data critical to their business operations. We build platforms our clients own, on infrastructure they control, and they can move to another host or self-host at any time.
Portal products are good software, and none of this makes them the wrong choice everywhere. When your rules fit their defaults and agents aren't likely to carry much of the work soon, a product is often the faster path. The calculation changes when the rules are the business, or when the agents are about to arrive.
How we'd build one
We don't sell an off-the-shelf portal. We're an agentic development consultancy with an agentically enabled software delivery model, which is what lets a custom build compete with a packaged one on time and cost. For a customer and partner portal, it would look like this.
Start from identity. Organizations, roles, delegated admins, partners and agents, each with permissions scoped to what they need. The platform we build on uses Ory for identity and access, with Postgres for data and Temporal for long-running workflows, all open source and running on Kubernetes.
Leave systems of record where they are. The ERP, CRM and support desk stay authoritative, and the portal works through their APIs rather than copying their data into a new master.
Build for one audience first. We'd rather put working software in front of your team (and perhaps select trusted partners and customers) early and refine it with them than research for months before anything exists. We ship working software in weeks, not months, and each audience after the first builds on the same foundation.
Keep the team small. A product lead, a platform engineer and product engineers work with agents throughout, so what we deliver with speed also meets exacting standards for quality, reliability, safety and control.
Three pieces of our published work show parts of that shape:
- Partners with their own brand. advisorDUO™, our work with Invesco, is a white-label application for the wealth management industry. Keeping it white label lets Invesco's partner investment dealerships use their own branding, and Invesco can uniquely configure it for each dealership from a single, brandable codebase. (Read the case study)
- Rules modeled inside the system. DesignDrive is a modern operations platform TOM Design Collective own outright. It covers projects, orders, proposals, purchase orders, invoicing, refunds and accounting, with retainers, credits and expenses as first-class structures and tax rates configurable per project and per jurisdiction. TOM have migrated off the legacy system and are running live client work on DesignDrive. (Read the case study)
- One platform behind more than one brand. For Hims & Hers, a blended Hims & Rangle foundation team built a new headless platform behind ForHers.com, and we then worked with them to merge the Hims and Hers platforms, including a UK acquisition. (Read the case study)
Where to start
If a portal is on the roadmap, three questions are worth answering before choosing a product or a partner.
- Who acts for whom? Map every delegate: partners, admins, reps, and the agents that will act for each of them.
- Which rules are yours? List the pricing, attribution and approval rules that make your channel work, and mark the ones a packaged product would make you change.
- What will agents do in the first year? Even a rough guess shows which actions need to be callable from day one.
If the answers say your rules fit a product's defaults, a product is probably the faster path. If they say the rules are the business, we'd be glad to talk through what a first working version could look like. Here's how we work.
