Orchestration, from the portal side

Declarative GitHub workflow orchestration, called from a developer portal

Declarative orchestration means a caller states which capabilities it wants rather than scripting how they run. Zekt orchestrates and correlates the GitHub workflow runs; Zekt Gate is what lets that request arrive from a developer portal carrying enterprise identity instead of a GitHub one.

Declaring work rather than scripting it

A scripted integration owns the sequence: call this, wait, check that, call the next thing, handle the retry. Every caller that wants the same outcome reimplements it, and the implementations drift.

A declarative request states the outcome. One request can name one or several Zekt services; the server side is responsible for executing and correlating them, and the caller receives output metadata it can act on. The sequence lives in one place instead of in every caller.

Where Zekt Gate fits, and where it does not

Zekt Gate does not orchestrate anything. It validates the identity presented, resolves the customer, authorizes the operation, and forwards the request to the same orchestration layer every other Zekt client uses.

That is worth being exact about, because the alternative is a second orchestration implementation living at the boundary — which would drift from the first one, and would have to be kept honest by nothing in particular.

Zekt owns

The Directory and the Registry
Service contracts and version semantics
Orchestration, execution and run correlation
Billing and every domain behaviour behind the boundary

Zekt Gate owns

Enterprise ingress and token validation
Identity translation into a Zekt request context
Authorization at the enterprise API boundary
API-level metering and provenance

Three clients, one platform

These are different interfaces into one platform, not three products. They converge on the same Directory, the same Registry, the same contracts and the same orchestration and correlation model — which is the property that makes the portal path worth having at all.

Zekt Action

The automation path. A workflow in GitHub Actions calls the native action; GitHub identity establishes the caller. This is the primary route and Zekt Gate changes nothing about it.

MCP

The agent path. Agents discover and use Zekt capabilities without a bespoke REST integration per service.

Zekt Gate

The enterprise API path. Interactive applications, developer portals and internal tooling, authenticating with corporate identity.