Control Plane Services

The platform is not one flat server file. It is a control plane with several service families behind it.

That matters because Agirunner is not just storing workflow rows in a database. The platform owns routing, review state, policy resolution, integration posture, and operator-visible records. Those are different kinds of concerns, and the code reflects that split.

Core Service Areas

From the codebase, the main service families include:

approval queue handling
workflow operations and guided closure
model catalog and assignment services
role-definition and specialist-skill management
remote MCP registration and verification
workspace and workspace artifact exploration
safetynet registration and control-plane recovery logic

What They Have In Common

These services are all control-plane concerns. They decide or record workflow meaning, not raw execution mechanics.

That is the simplest way to tell platform code from runtime code. If the logic decides whether work should exist, how it should be routed, what review state applies, or what operators should see, it is usually a platform concern.

Why This Split Matters

When a problem involves:

approval legality
workflow closure
model assignment
workspace records
operator-facing control state

it usually belongs in platform services rather than in the runtime.

How It Connects To The Rest Of The System

These service families are the machinery behind the more visible product surfaces:

Dashboard is where operators interact with the results of these control-plane services
Workflow Activation And Routing explains how the platform turns state into fresh executable work
Artifact, Log, And Workspace Services explains how evidence and continuity become durable product state
Runtime Overview shows the separate execution system these platform services supervise rather than replace

This page is the architectural view. The dashboard pages are the operator view built on top of it.