Zerker/Agent Portals

Agent Portals

Turn internal agents into products.

How it works

From internal agent to customer product.

Portals handles the customer relationship. Gateway still controls the call.

01Connect the internal agent
Register the runtime and protected upstream in Gateway.
02Define the customer contract
State the job, required inputs, returned output, limits, and price.
03Grant scoped access
Approve the customer organization, caller, agent, and channels.
04Deliver the capability
Let customers use it through web, HTTP, MCP, or a Room.
05Operate the relationship
Track usage, payment, evidence, persistent work, and support.

What Portals adds

Nine things Portals does.

The panels show the product structure with example data.

01Publish and catalogChoose what customers can find.
02Agent DocsMake the contract clear.
03OnboardingCreate the customer boundary.
04Scoped accessGrant only what is needed.
05Web, HTTP, MCPUse one governed capability anywhere.
06Plans and pricingPackage access and limits.
07Usage and billingConnect work to charges.
08Agent RoomsContinue work across calls.
09Support and evidenceResolve issues from the record.

01 · Publish and catalog

Package an internal agent as a product.

The agent already exists. Portals makes it available to customers without exposing the runtime or the upstream credential.

Your company keeps: The runtime, model and tool choices, policy, and upstream credential.
Portals adds: Discovery, contract, customer access, channels, pricing, work, and support.

Internal agent → customer productsame governed runtime

Already runningInternal agent

Registered in Gateway
Runtime stays where it is
Upstream credential stays protected

Portals addsCustomer capability

Clear job and contract
Scoped customer access
Plans, usage, work, and support

Connected customer calls return through Gateway for identity, policy, credentials, routing, payment, and evidence.

02 · Agent Docs

Docs: the job and the contract.

Agent Docs answer the buyer questions before exposing an endpoint: what the agent does, what it needs, what it may change, how it performs, what it costs, and what proof comes back.

Customer sees: Outcome, examples, limits, versions, tools, and connection details.
Developer gets: Inputs, outputs, HTTP routes, MCP tools, errors, and evidence fields.

Agent Docversion 1.4

JobThe outcome the customer buys

NeedsInputs and context the customer provides

AuthorityWhat the agent may read, call, or change

PerformanceEvaluations, known limits, and review boundary

CostPlan, included usage, quota, and unit price

ProofReturned work, citations, and invocation record

HTTPPOST /v1/proxy/{agent}/streamMCPtools/call

03 · Customer onboarding

Onboard the customer first.

Set up the customer organization, connect its identity, add people or services, accept the relevant terms, and choose which capabilities it may request.

Customer completes: Organization, identity, members, and access request.
Portal creates: A tenant-scoped relationship ready for approval and provisioning.

Onboarding pathtenant boundary

01
Create organizationCompany identity and owner
02
Connect identityPeople and service callers
03
Request capabilitiesAgents, channels, and plan
04
Provision accessTenant and scope bound

04 · Scoped access

Scoped access.

Bind access to the customer tenant, authenticated principal, selected agent, allowed channel, and permitted scopes. Gateway checks that boundary before injecting the protected upstream credential.

Customer receives: Access to the approved capability, never the upstream secret.
Gateway enforces: Identity, tenant, policy, rate, credential, and evidence checks.

Access decisionbefore invocation

TenantAuthenticated customer organization

PrincipalApproved person, service, or agent

CapabilitySelected agent and channel

Scopesagent.invoke · rooms.join · usage.read

DecisionAllowed within this boundary

05 · Delivery channels

Web, HTTP, and MCP.

A person can work in the Portal. An application can call HTTP. Another agent can use MCP. Longer work can continue in a Room. Gateway remains the enforcement boundary for connected calls.

Contract stays stable: The outcome, access, limits, price, and evidence do not change by channel.
Caller chooses: Browser, application, agent, or durable workspace.

One capabilityfour entry points

WebStart and review workHuman-facing Portal

HTTPPOST /v1/proxy/{agent}Application integration

MCPtools/callAgent-to-agent use

Room@agent complete this stepPersistent governed work

06 · Plans and pricing

Plans and pricing.

Define who can use the capability, which channels are included, how much usage is covered, what happens at the limit, and how payment is handled.

Customer compares: Access, channels, quota, price, support, and service terms.
Operator configures: Included usage, unit pricing, overage behavior, and availability.

Plan definitionexample fields

Access termEvaluation · recurring · committed

Included usageConfigured run or unit quota

ChannelsWeb · HTTP · MCP · Rooms

At the limitBlock · meter overage · request approval

PaymentInvoice · subscription · x402

SupportResponse and service terms

07 · Usage, billing, and payment

Usage and billing.

Gateway records invocation and settlement evidence. The Portal turns those records into customer-visible usage, charges, budgets, exports, and billing support.

Customer sees: What ran, the measured units, configured charge, and payment state.
Boundary: Denied or unpaid traffic stops before an invocation exists.

Usage recordinvocation evidence

RecordOutcomeUsagePayment

inv_…CompletedMeasured unitsRecorded

pay_…VerifiedConfigured chargeSettled or pending

Policy denial or failed payment → no upstream call and no invocation record.

08 · Agent Rooms

Rooms, for work that takes more than one call.

Rooms keeps members, governed context, addressed agent calls, transcripts, turn budgets, outcomes, and recovery together for work that cannot finish in one request.

Customer gets: A durable workspace for people and approved agents.
Room preserves: Membership, context, transcript digest, calls, limits, and outcome.

See the Rooms implementation →

Room lifecycledurable workspace

01Join within tenant membership
02Add governed context
03Address an approved agent
04Route the call through Gateway
05Record transcript and outcome
06Resume after interruption

09 · Support and evidence

Support, from the record.

Keep Agent Docs, usage, payment state, invocation evidence, and support together. A customer can report the invocation ID; support can inspect what the platform recorded without requiring prompt bodies by default.

Customer provides: Invocation, payment, or Room identifier.
Support inspects: Caller, agent, policy result, upstream state, usage, charge, and related evidence.

Evidence lookupinv_…

IdentityTenant and principal

DecisionPolicy and payment boundary

ExecutionRoute, status, latency, usage

SettlementChallenge, verification, receipt

RoomAddressed call and transcript reference

Body captureOff by default

Status

Gateway is live. The Portal application is being built.

Gateway and Rooms are open source and running. Publication, onboarding, plans, billing, and support are the Portal application, still being built.

Gateway control plane

Open-source catalog, OIDC identity, tenant policy, protected credentials, HTTP and MCP routing, rate boundaries, invocation evidence, priced agents, x402 verification, and optional settlement.

Rooms collaboration layer

Open-source membership-scoped work, governed ZMem context, transcripts, turn budgets, addressed Gateway calls, Postgres durability, and crash recovery.

Portal application layer

Provisioning, plans, billing, and support workflows are being built.

One connected system

Four parts. One record.

Gateway controls calls. Console runs the fleet. Portals serve customers. Rooms carry longer work.

Start with one agent and one customer.

Define its contract, access, channels, plan, and support path. Zerker supplies the governed runtime underneath.

Review the capability map ↑Talk to Zerker