This document defines how K0nsult maps static registry profiles to live runtime roles. Every agent profile in the registry (2,000+) is a capability blueprint. To become operational, it must be mapped to a runtime role with specific permissions, tools, and constraints. This mapping is the bridge between catalog and execution — between what an agent can do and what it is allowed to do in a given deployment.
Section 1
The Mapping Model
Every agent profile in the registry (2,000+) is a capability blueprint. To become operational, it must be mapped to a runtime role with specific permissions, tools, and constraints. The mapping pipeline ensures that no agent enters production without explicit authorization, tool scoping, data classification, and policy binding.
Registry Profile
→
Role Assignment
→
Tool Access
→
Policy Binding
→
Deployment
→
Runtime Instance
Registry Profile — The stored capability definition: skills, domain expertise, authority level, sector certifications.
Role Assignment — A specific operational role within a workflow (e.g., "Compliance Checker" within an audit pipeline).
Tool Access — Explicit allow/block list of tools the agent can invoke at runtime.
Policy Binding — Data classification, escalation thresholds, and autonomy caps enforced by the governance layer.
Deployment — Environment provisioning: staging vs. production, resource allocation, monitoring hooks.
Runtime Instance — The live, active agent executing tasks within its scoped permissions.
Section 2
Runtime Role Card Schema
Every agent mapped to runtime receives a Role Card — a structured record that defines its operational boundaries. The Role Card is the single source of truth for what an agent is allowed to do, access, and decide at runtime.
role_id
string · unique
Unique runtime role identifier
ROLE-TECH-K02-001
profile_source
string · registry reference
Registry profile ID this role maps from
TECH-K02
allowed_tools
array<string>
Tools the agent can invoke at runtime
[n8n_webhook, api_call, db_read]
blocked_tools
array<string>
Tools explicitly denied to this agent
[db_delete, fund_transfer, email_send]
allowed_data_class
array<string>
Data classification tiers the agent can access
[internal, public]
blocked_data_class
array<string>
Data classification tiers blocked from access
[PII, financial, regulated]
approval_rights
array<string>
Actions this agent can approve autonomously
[Level A: auto-classify, auto-route]
escalation_rights
array<string>
Conditions that trigger mandatory escalation
[confidence < 85%, amount > $1000]
sector_fit
array<string>
Target industry sectors for this role
[tech, ecommerce]
workflow_fit
array<string>
Compatible workflow types
[support_triage, content_review]
max_autonomy
enum: A | B | C | D
Highest decision level the agent can exercise
Level B
kpi_targets
object
Performance requirements measured in real-time
{accuracy: 95%, escalation_rate: <15%}
deployment_status
enum
Current operational state of this runtime role
ACTIVE / STANDBY / TESTING
Section 3
Sample Mappings — 10 Agents
The following table shows 10 representative agents mapped from their registry profiles to runtime roles. Each row demonstrates how a static profile becomes a bounded, operational instance.
| Registry Profile |
Runtime Role |
Allowed Tools |
Data Access |
Max Autonomy |
Workflow |
Status |
| TECH-K02 |
Strategic Advisor |
api_read, report_gen |
internal, public |
Level B |
strategic_briefing |
ACTIVE |
| LAW-LegalRep |
Compliance Checker |
policy_lookup, doc_gen |
internal, regulated |
Level C |
compliance_audit |
ACTIVE |
| TECH-Grid |
Architecture Reviewer |
code_review, api_call |
internal |
Level B |
tech_review |
ACTIVE |
| QA-GateTurner |
Quality Gate |
test_run, report_gen |
internal |
Level A |
quality_check |
ACTIVE |
| COM-CommsRep |
Outreach Manager |
email_draft, crm_read |
internal, public |
Level B |
outreach |
STANDBY |
| AUDIT-Ledge |
Audit Executor |
db_read, report_gen, replay |
all (read-only) |
Level C |
full_audit |
ACTIVE |
| TECH-Titan |
System Architect |
api_call, diagram_gen |
internal |
Level B |
architecture |
TESTING |
| RISK-Vault |
Risk Assessor |
risk_calc, alert_gen |
all (read-only) |
Level A |
risk_scoring |
ACTIVE |
| MGT-Orion |
Program Director |
task_assign, status_track |
internal |
Level C |
program_mgmt |
ACTIVE |
| MOD-MOLT-MOD |
Content Moderator |
content_scan, flag_gen |
public, moderation |
Level B |
moderation |
ACTIVE |
Click any column header to sort. Status colors: ACTIVE = live in production,
STANDBY = ready but not deployed,
TESTING = under validation.
Section 4
Mapping Rules Engine
The following rules are applied automatically during the registry-to-runtime mapping process. These rules enforce governance constraints before any agent becomes operational. Violations trigger a HOLD state and require human review.
Rule 1 — Process Risk HIGH → Agent max_autonomy capped at Level C (advisory only, human decision required)
Rule 2 — Data class PII / financial → Agent must have explicit data access grant in its Role Card. No implicit inheritance from registry profile.
Rule 3 — Sector = banking → Only agents with banking_ops certification in their registry profile may be mapped to banking workflows.
Rule 4 — Workflow = customer-facing → Require human_oversight flag at the output stage. No direct customer-facing output without review gate.
Rule 5 — Agent confidence < threshold → Auto-escalate to next authority level. Threshold defaults to 85% but is configurable per workflow.
Rule 6 — First deployment → New agents start in TESTING status for minimum 72 hours before promotion to ACTIVE.
Rule 7 — Violation count > 0 → Agent must pass re-certification before runtime re-activation. Autonomy level downgraded by one tier during probation.
Section 5
Registry vs Runtime Comparison
The registry and runtime layers serve fundamentally different purposes. Understanding this distinction is critical for correct agent governance.
| Aspect |
Registry (Catalog) |
Runtime (Operational) |
| Purpose |
Define capabilities |
Execute tasks |
| Count |
2,000+ profiles |
10–50 active per deployment |
| Permissions |
Described (declarative) |
Enforced (runtime policy engine) |
| Data Access |
Listed as capabilities |
Controlled by policy engine |
| KPI |
Defined as targets |
Measured in real-time |
| Status Model |
Active / Inactive |
ACTIVE / STANDBY / TESTING / SUSPENDED |
| Mutability |
Updated by registry admin |
Modified by runtime policy & governance events |
| Lifecycle |
Persistent catalog entry |
Ephemeral: created, suspended, terminated per deployment |
Registry (Catalog)
Nature Static blueprint — describes what an agent can do
Ownership Maintained by CNC registry administrators
Update Frequency On profile change, certification, or version bump
Access Control Read: all authenticated users. Write: registry admins only
Audit Trail Version history per profile
Runtime (Operational)
Nature Live instance — defines what an agent is allowed to do now
Ownership Governed by deployment policy engine + human oversight
Update Frequency Real-time: on policy change, incident, or governance event
Access Control Scoped per Role Card — tool-level, data-level, decision-level
Audit Trail Full decision log with timestamps, escalations, and overrides
Section 6
API for Runtime Mapping
Three endpoints manage the runtime mapping lifecycle: assign a registry profile to a runtime role, query active runtime agents, and suspend a runtime agent (per-agent kill switch).
POST
/api/agents/map-to-runtime
Assigns a registry profile to a runtime role. Creates a mapping record with tool permissions, data access scope, and autonomy level. Logs the mapping as a decision event for audit.
- profile_id
- string (required) — Registry profile ID (e.g., "TECH-K02")
- role_id
- string (required) — Runtime role identifier (e.g., "ROLE-TECH-K02-001")
- allowed_tools
- array<string> — Tools the agent can use at runtime
- blocked_tools
- array<string> — Tools explicitly blocked
- allowed_data
- array<string> — Data classification tiers accessible
- max_autonomy
- string — Maximum autonomy level (A, B, C, D)
- workflow_fit
- array<string> — Compatible workflow types
{
"ok": true,
"profile_id": "TECH-K02",
"role_id": "ROLE-TECH-K02-001",
"status": "MAPPED",
"timestamp": "2026-03-23T14:30:00.000Z"
}
GET
/api/agents/runtime-status
Returns all active runtime agents, ordered by confidence score (descending). Maximum 50 results. Used by dashboards and monitoring systems to display current operational state.
{
"ok": true,
"agents": [
{ "agent_id": "TECH-K02", "status": "ACTIVE", "nick": "K02", "confidence_avg": 0.94 },
{ "agent_id": "AUDIT-Ledge", "status": "ACTIVE", "nick": "Ledge", "confidence_avg": 0.91 }
],
"count": 2
}
POST
/api/agents/suspend-runtime
Suspends a runtime agent immediately. This is the per-agent kill switch. The agent's status is set to SUSPENDED and a decision record is logged with the reason and operator identity. Requires re-activation through the mapping endpoint to restore.
- agent_id
- string (required) — The agent to suspend
- reason
- string — Justification for suspension
- suspended_by
- string — Operator or system that triggered the suspension
{
"ok": true,
"agent_id": "TECH-K02",
"status": "SUSPENDED",
"timestamp": "2026-03-23T15:00:00.000Z"
}