The runtime and the rules
Where the agent runs, which model and tools it uses, the policy it obeys, and the upstream credential it never hands to a person.
Zerker/Governance for Workforce
Workforce · the first rung
Give your workforce approved agents, without giving up control.
The company runs the agents. People just use them: through your identity provider, in Slack, Teams, an IDE, or an API, with every call passing through Gateway policy.
The workforce path
Sign in, find an agent, use it where you work.
Every call passes through Gateway policy. No one on the team holds the upstream credential, and every routed call leaves an invocation record.
- 01Sign in
Your identity provider supplies the person, tenant, team, and role.
OIDC · TEAMS - 02Find
People see the approved agents assigned to their team, with a clear job and contract.
CATALOG - 03Get access
Access arrives by role, or on request with an owner's approval.
SCOPED ACCESS - 04Launch
Use the agent in the web, Slack, Teams, an IDE, a command line, or over the API.
WEB · SLACK · IDE · API
The model
The company runs the agents. People do not bring their own.
Zerker connects agents that already run somewhere: an internal service, a Claude Code or Codex session, an agent on OpenAI, Anthropic, Bedrock, or Vertex, an MCP server, a vendor-hosted agent, a Slack or Teams agent, or one deployed in your own cloud. Then it sits between the organization, its workforce, those agents, and the systems they can reach.
Rollout
Six steps from scattered agents to a governed workforce.
Most companies do not start clean. Different teams already use ChatGPT or Claude, Cursor or Claude Code, a sales research agent, internal data agents, Slack automations, and things individual engineers built. Zerker starts by organizing what exists.
- 01Connect identity
Okta or Google Workspace supplies people, teams, roles, business units, and access groups.
OIDC - 02Build the inventory
Import or register each agent with its owner, runtime, and users.
CATALOG - 03Assign owner and policy
Who owns it, who can use it, what it can reach, which actions need approval, and its cost limit.
POLICY - 04Connect the runtime
Register an API-backed agent's endpoint and credentials, or add an adapter to a local one.
ROUTE - 05Label what you cannot route
An agent that does not pass through Gateway is shown as observed, never as governed.
OBSERVED · GOVERNED - 06Publish to the workforce
People sign in, see the agents assigned to their team, and launch them where they work.
DELIVER
Delivery truth
What Gateway enforces today, and what Zerker is building on it.
Gateway governs workforce traffic now: identity from your provider, tenant boundaries, ordered policy, protected credentials, and an invocation record for every routed call. The Workforce Portal, where people browse, request, and launch approved agents, is the delivery layer Zerker is building on those same records. Zerker governs only the calls routed through it, and never claims enforcement it does not have.
The ladder
Workforce first. Then partners. Then customers.
The same governed record serves each audience in turn. Start with your own people, extend selected agents to partners, then publish the ones that are ready to customers through Agent Portals.
Start with one team and one approved agent.
Connect your identity provider, register the agent, and give one team access through Gateway.