ZerkerPortals

Zerker/Agent Portals

From internal capability to customer product

Turn an internal agent into a product customers can use.

Your company already has useful agents. Portals adds the customer product layer: a clear contract, scoped access, web and agent channels, plans, usage, billing, persistent work, and support. Decide which agents each partner can reach and at what limits, or open a self-serve Agent Portal, hosted wherever you choose, so agent traffic and the long tail of customer requests land on a page you own. Gateway keeps control of every connected call.

See how it works →Build your Agent Portal

How it works

Take an agent your company runs and make it available to customers.

Portals handles the customer relationship around the agent. Gateway still controls identity, policy, credentials, routing, payment, and evidence for the call itself.

  1. 01Connect the internal agent

    Register the runtime and protected upstream in Gateway.

  2. 02Define the customer contract

    State the job, required inputs, returned output, limits, and price.

  3. 03Grant scoped access

    Approve the customer organization, caller, agent, and channels.

  4. 04Deliver the capability

    Let customers use it through web, HTTP, MCP, or a Room.

  5. 05Operate the relationship

    Track usage, payment, evidence, persistent work, and support.

What Portals adds

Nine functions around the agent.

The canvases show the product structure, not a fictional customer account or live activity.

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

Wrap an internal agent with the product customers expect.

The useful agent already exists. Portals turns its governed Gateway record into a customer-facing capability without exposing the runtime or protected 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

Explain the job and the technical 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

Create the customer boundary before issuing access.

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
  1. 01
    Create organizationCompany identity and owner
  2. 02
    Connect identityPeople and service callers
  3. 03
    Request capabilitiesAgents, channels, and plan
  4. 04
    Provision accessTenant and scope bound
04 · Scoped access

Grant the caller one clear boundary.

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

Use the same governed capability where the work happens.

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

Package access without changing the agent.

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

Connect every completed call to usage and money.

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

Move from a call to a complete piece of work.

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
  1. 01Join within tenant membership
  2. 02Add governed context
  3. 03Address an approved agent
  4. 04Route the call through Gateway
  5. 05Record transcript and outcome
  6. 06Resume after interruption
09 · Support and evidence

Resolve the issue from the exact 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

Delivery truth

The control plane exists. The managed Portal application is being built.

Gateway and Rooms provide the source-backed runtime underneath this capability map. The customer publication, onboarding, plan management, billing, and support application workflows remain in development.

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

The capability map defines the customer product surface. Managed provisioning, plan operations, subscription billing, and support workflows are still being built.

One connected system

Gateway controls calls. Console runs operations. Portals serve customers.

Rooms carries persistent customer work underneath the Portal without becoming another top-level product.

Connect and govern

Agent Gateway

Control who can call, what can run, which credential reaches the upstream, what it costs, and what gets recorded.

See Gateway →
Operate

Operator Console

Manage the catalog, investigate invocations, watch settlement state, and work conditions that need an owner.

See Console →
Publish and deliver

Agent Portals

Turn selected governed agents into customer capabilities with clear contracts, access, usage, work, and support.

Review capabilities ↑
Deliver durable work

Agent Rooms

Keep members, governed context, transcripts, turn budgets, addressed Gateway calls, and outcomes together.

See Rooms →

Start with one agent and one clear customer outcome.

Map its contract, access boundary, channels, plan, evidence, and support path. Zerker supplies the governed runtime underneath it.

Review the capability map ↑Talk to Zerker