One workspace per client, one flat bill answers the question agencies ask first: does the pricing model punish us for growing? It does not — that piece covers the mechanics in detail. This one is about a different question, and one that matters more for agencies trying to differentiate rather than just survive their tooling bill: what can you actually build on top of a client workspace, beyond logging into it and clicking around?

The honest answer is that most agency software, Norbelys included, gives you a dashboard to operate manually. What changes that equation is the MCP server at mcp.norbelys.com/mcp — roughly 82 tools generated from the same contract as the REST API, authenticated with a bearer token scoped to one organization. For an agency running client workspaces, that’s not just “AI agents can use the product.” It’s a building block for tooling that’s yours, not the vendor’s.

Reselling a dashboard vs. building your own layer

Most agency software has one distribution model: you get a dashboard, optionally with your logo on it, and your client either uses it directly or watches you use it. The ceiling on that model is fixed by what the vendor decided to build. An MCP server changes the ceiling, because the building block isn’t a screen — it’s a scoped credential and a set of callable tools that any agent you write can use.

	White-label dashboard resale	Build on the MCP server
What you're selling	Access to someone else's UI with your logo	Your own workflow, running on top of the platform
Differentiation ceiling	Whatever the vendor's roadmap ships next	Whatever your team can script
Client-facing surface	A relabeled dashboard	A Slack bot, a report, a QA check — your choice
Vendor dependency	Full — your product is their product	Partial — the platform does sending and deliverability; you build the interface

Neither model is wrong. A reselling arrangement is genuinely the right fit for an agency that wants to hand a client a login and move on. But it means the thing you’re charging for is mostly the vendor’s work with your color scheme on it. Building your own layer on top of a real API — and Norbelys’s MCP tools are exactly the platform’s real API, not a limited subset — means the thing you’re charging for is actually yours: a specific workflow, tuned to how your agency operates, that a client can’t get by signing up for the platform directly.

Two concrete things an agency could build

Two shapes come up often enough that they’re worth describing specifically, because “AI workflows” is vague until it’s a named thing with an input and an output.

A client-facing reporting agent. Instead of a live report link (which Norbelys already provides, and which carries Norbelys branding — see the honest caveat in the flat-bill piece), an agency could build a small agent that calls organization_pulse and analytics_query for a client’s workspace on a schedule, then posts a plain-language summary into that client’s Slack channel: campaigns running, human reply rate, any mailbox that dropped out of healthy. The report is generated by your agent, phrased however your agency phrases things, delivered wherever your client already looks. The vendor branding problem disappears because the surface your client sees isn’t Norbelys’s UI at all — it’s your Slack bot, built on tools the platform exposes.

An automated QA-check agent. Before a new sequence launches for a client, an agent could run a checklist against the MCP tools: verify the attached senders are healthy, confirm the segment’s contacts have passed verify_email, check that suppression rules are attached, and only then surface a “ready to launch” signal to whoever on your team has to approve it. programs_launch carries a destructiveHint annotation for a reason — a well-behaved agent asks a human before it fires — so this isn’t about automating away the launch decision. It’s about automating the tedious pre-launch verification that a person currently has to remember to do by hand, for every client, every week.

The credential is what makes this safe to build

The part of this that’s easy to overlook, because it’s infrastructure rather than a feature, is that the whole idea only works safely because of how the credential scoping lines up with the workspace model. Every client gets their own workspace under the flat-bill model, and every API key an agency creates is scoped to a single organization. An agent built to serve Client A, authenticated with Client A’s key, structurally cannot read or write Client B’s data — there’s no org parameter to pass, no shared pool a misconfigured agent could accidentally reach across. That means an agency can run the same reporting-agent code for every client on its roster, swap only the credential, and get the same isolation guarantee the dashboard already gives a human logging in. The multi-client architecture that makes the pricing model work is the same architecture that makes agent-built tooling safe to run at scale.

Starting smaller than a full agent

None of this requires building a sophisticated autonomous system on day one. The two examples above both start as a script that runs on a schedule and calls two or three tools — closer to a cron job with an API key than an “AI agent” in the ambitious sense. A first version of the reporting bot might just be organization_pulse piped into a Slack webhook once a day, with no language model involved at all. The “AI” part — summarizing in plain language, flagging what’s unusual rather than just dumping numbers — is a layer you add once the plumbing already works and you’ve decided it’s worth the added complexity. Starting with the plumbing means the first version ships in an afternoon instead of a quarter, and it’s already useful before a single prompt gets written.

Why this matters specifically for agencies

A single company building an internal agent on top of Norbelys gets a convenience — fewer dashboard clicks for their own team. An agency building the same kind of agent gets something closer to a product: a workflow that can run, largely unchanged, across every client workspace they manage, each authenticated with that client’s own scoped API key. The reporting agent above isn’t a one-off script for one client — it’s a template your agency runs for all twelve, adjusting only which credential it authenticates with. That’s the part reselling a dashboard can’t give you: the workflow is the product, and it scales the way your agency does, not the way the vendor’s release calendar does.

It’s also where the GitHub agent kit is meant to help rather than leaving you to read tool schemas cold — AGENTS.md, agent skills, and Cursor rules for how an agent should use Norbelys, so your first build isn’t a blank page. Pair that with agent authentication for the OAuth or API-key details, and the starting point for a client-scoped agent is a few hours of setup, not a research project.

The honest scope of this

This isn’t a claim that every agency should stop using the dashboard and start writing agents. Most of the day-to-day work — reading a reply thread, judging whether copy lands — still wants a human looking at a screen, and the dashboard is genuinely the right tool for that. What changes is the option: an agency that wants to differentiate with its own tooling, rather than a relabeled version of someone else’s, now has a real API surface — the same one the CLI and SDKs are generated from — to build that tooling on. The workspace-per-client model from the flat-bill piece is what makes running that agent across a dozen clients safe in the first place: each client’s data, senders, and reputation stay isolated, regardless of which agent or credential is calling in. For the full picture of what an agency workspace includes, see the agency page; for what a client can already see without any custom build, agency reporting is the baseline you’d be building on top of.