Designing role-based AI teammates

Core concepts

ZephMatrix treats each AI teammate as a role with clearly defined responsibilities and constraints. A few concepts show up throughout the product and other documentation:

• Role blueprint – the configuration document that describes a teammate's scope, capabilities, guardrails, and required tools.
• Teammate – an installed role that is active in a specific workspace and can be monitored from the dashboard.
• Guardrail policy – the set of rules that constrains which actions are allowed, blocked, or require approval.
• Approval workflow – the logic that decides when to auto-approve a task versus pause it for human review, based on the guardrail policy and risk level.

Role blueprint structure

Every teammate is defined by a structured role blueprint. At a high level, a blueprint captures:

• • Name and description of the role
• • Scope and responsibilities (what problems it owns)
• • Capabilities and guardrails (what it can and cannot do)
• • Required tools and integrations

Blueprints are created through the Hire Role flow or by installing templates from the marketplace.

Role templates and installation

You can start from a template in the marketplace or define a custom role. Templates capture a proven configuration for a particular job (for example, customer support triage or marketing analyst) and can be installed into your business.

Installed teammates show up in Dashboard → Active Roles, where you can review configuration, connect integrations, and monitor basic performance.

Capabilities and guardrails

A role's capabilities describe which actions it can take and which tools it can call. Guardrails define:

• • Which actions are blocked outright
• • Which actions require approval (by pattern or type)
• • Cost and iteration limits per task

These settings are enforced by the GuardrailEnforcer and used as inputs to the approval engine, which decides when to auto-approve versus pause for human review.

Autonomy levels

Roles can be configured with different autonomy levels (for example, shadow, guided, or more autonomous behavior). Today, autonomy is primarily expressed through guardrails and which tasks are allowed to execute without approval.

For example, a low-autonomy teammate might require approval for any external changes, while a higher-autonomy teammate can execute low-risk actions directly but escalate high-risk actions for review.