A few years ago we bought a ‘chalet’ in the hills outside of Montreal.

Lake days the summer, ski days in winter, and we mostly enjoy time with family all year long. We also spent the odd day by our pool.

We recently made the decision to fill in the pool and turn it into a yard.

The pool was old, the pool house needed a lot of work, and the fence looked like it was straight out of a horror movie.

This was controversial. Several friends lobbied against it - I reminded them that if they wanted to subsidize the upgrades and pay to maintain it, they were more than welcome.

There were no takers.

What I thought was a simple job turned out to be layered.
Permits. Bylaws. Electrical that had to be disconnected. Excavation, landscaping, cleanup...

Through it all, I dealt with one person only. The orchestrator (you see where I'm going with this).

He figured out the permits, the fill, the seed, the design, the sequencing, all of it - he also did the excavation himself.

There were a lot of people doing specific jobs underneath him and I never met most of them.
I had him on text - when something was blocked or he needed my input, we spoke, aligned, and he kept me in the loop.

Did I want to deal with everyone involved and coordinate?
Did I want to deal with the company?
Or did I want to deal with one person who managed everyone else and represented the company?

There's an almost identical question sitting in front of most product teams right now.

We're getting asked some version of it weekly: “what should customers experience when our product becomes agentic?”

• Should your product just be agentic, with no agent to talk to?
• Should it become the agent?
• Should it have one agent, a whole team of them, other people's agents...
• Should it be a blank canvas where your customers build their own agents?

There are 6 recognizable strategies (today), each making a different bet about where trust lives.

The spectrum, and how to read it

The spectrum runs left to right on one axis: how much agent presence the customer actually experiences.

• On the far left they experience only the product with ‘enhanced capabilities’.
• On the far right they're in the driver's seat, building the agents themselves.

Underneath the dotted line is what's actually running. That part is illustrative, not architectural. This isn't a build guide.

Let's get into them:

1. The agentic-powered product

The product as they know it.

No standalone agent to interact with. AI capabilities woven into the workflows customers already live in.

The classic example is Gmail before Gemini showed up. Smart compose, autocomplete, a handful of things that make managing your inbox easier. No new surface to adopt, no new relationship to form. Clay is the sharper modern version, where AI research runs inside spreadsheet cells and the intelligence is a column rather than a colleague.

This path asks the least of your customer. It also asks the most of your team, because you have to be precise about jobs to be done and intent, and the surfaces have to be embedded elegantly or the whole thing feels bolted on.

The trust note: there's no new relationship to earn. Trust rides on the product they already use. That's a gift and a liability - if the AI is wrong, it's your product that was wrong.

2. The single product agent

One agent. One relationship. There may be a dozen specialists working backstage, and there probably should be, but the customer only meets one.

Rufus at Amazon. Erica at Bank of America. Fin at Intercom - which is the most interesting case study on the board because Fin effectively became the product.

The trust note is the cleanest on the whole spectrum: trust accrues in one place, and the machinery stays invisible. One relationship to earn, one track record to build, one thing to hold accountable.

This is the guy-who-did-my-yard model, and the two exceptions from my yard are the design brief.

1. My trust accrued to him - when he needed me he asked, when he didn't, I let him cook
2. There were some things better handled by others, directly with me - like billing. This is the equivalent of managing your CC or paying your subscription through a settings/profile instead of with the agent. Some things belong in familiar places, and the agent can always answer questions or nudge you there if needed.

I think a lot of products will toggle between strategy one and strategy two, and eventually the two will merge.

3. A team of product agents

Now you ship a roster. Copy agent, nurture agent, outreach agent, all built by you, all out of the box.

HubSpot Breeze, Notion agents... Each one of those agents is a new feature the customer has to learn. I used to write copy this way. I used to nurture leads this way. Now there's an agent doing it on my behalf, and I have to learn what it's good at.

Individually each one feels low-barrier. Stacked on top of each other, it could become a burden if this is the strategy for every ‘job-to-be-done’.

The trust note: trust splits across the roster and may accrue to the product itself as the ‘home’ for these agents. The customer becomes the manager. If one agent underperforms, it doesn't stay contained to that agent. The brand gets muddied. And you now have to control quality across a whole lineup rather than one.

Because of that management overhead and that fractured trust, I think a single orchestrator starts to emerge here. A control center.

4. Product agents plus custom agents

Your roster, plus a builder so customers can make their own.

Agentforce with Agent Builder. Glean, where you get the Glean assistant and the agent builder on the same permissioned index. Copilot Studio, where Microsoft reported that 160,000 organizations built more than 400,000 custom agents in the first 90 days (is this a good metric? I don't know...).

Those numbers are real and the exploration and enthusiasm is real. But I keep asking how AI-alpha this behavior is.

Building your own agents is a knowledge-work move, and probably a specific kind of knowledge worker. I don't see it as the prevalent path for consumer products, or even for every role inside a B2B product unless the UX for building agents becomes as easy as chatting (Grokbot did a good job here) and managing them becomes seamless.

The trust note gets harder: quality varies enormously between native and custom.
The agent your customer built badly still shows up next to yours.

One prediction: the more you tell customers to build agents for their org, the more their adoption problem becomes your problem. And today, that can get solved through FDE's/support, or great design.

5. Product, custom, and third-party agents

Now you're the hub, and everyone's invited to the party.

Slack is the clearest example. Slackbot as the first-party agent, Agentforce as the custom ‘native agent’ layer, and a marketplace of thousands of partner agents (and apps). Salesforce is explicit that Slackbot is the router: your personal agent for work that surfaces context and dispatches your third-party agents from one conversation.

Linear is the better case study, because they didn't start here. It started with Triage Intelligence suggesting labels and assignees, then shipped its own agent in March, and opened the roster to Claude Code, Devin, Cursor and Copilot through an Agent API where outside agents appear as first-class workspace members. Their design principle is humans and agents as peers (a common one you're seeing now).

The trust note: scalability is high and trust can be outsourced, for better or worse.

This is also, not coincidentally, where the vendor keeps the revenue while the customer absorbs the quality risk.

Customers are starting to notice that trade.

6. Platform of custom agents

Product as a platform. The customer hires, trains, and manages the whole team.

Grok Bot from xAI is the live version of this. The recommended setup literally starts with a Chief of Staff agent that reviews your connected apps, proposes a roster, names them, writes their instructions, and tracks what each one is working on. Org design as a product feature.

The trust note: high user agency, high functionality, and a metaphorical ceiling on number of tools in your toolbox (or teammates you can manage). You can only manage so many relationships, synthetic or otherwise. Unless the Chief of Staff or orchestrator agent is designed well, the customer drowns in the management layer.

Which is why I think the orchestrator becomes the default entry point here, and eventually becomes a customizable product-native agent rather than something the customer has to assemble.

Where to start

Pick the strategy that matches where your trust already lives and where your customers mental models will make the smallest jump.

If your customers trust the product and not any agent inside it, start at one or two.

If you're about to ship a roster, budget for the orchestrator before you budget for the fifth agent.

If you're opening a builder, make sure you know why you're doing it and what you hope to see or learn as people start building their ‘teams’.

Just make sure trust is something you're building, not breaking.

— Theo