Skip to content
Customer Docs

The Agent Team

Tectonic Agents uses exactly six customer roles in each account. Platform services and temporary workflow stages support that team, but they are not extra permanent personas.

Exactly six agent roles

These are the six customer-facing roles in your agent team. Each role stays inside your account boundary, follows the platform’s metering and trust rules, and must stop when its evidence or capability path is missing.

Orchestrator

Observe / propose

The agent team’s main loop. It classifies requests, routes to a specialist, keeps your account context and skills available, and schedules bounded follow-up work. It cannot self-approve a change.

Server Manager

Propose; act only when gated

The server-evidence and bounded-operations role. Panel actions require the right account ownership, credentials, trust, metering, and a real integration. When one of those gates is missing, it reports the operation as unavailable instead of simulating it.

Support

Observe

A read-only support specialist grounded in your account’s documents, rules, history, and approved current sources. It answers and escalates; it does not change a server or community policy.

Moderation

Opt-in · act-on-chat only

An optional, off-by-default chat policy pipeline. Deterministic filters run first, bounded triage handles edge cases, and uncertainty or missing permissions stops at a human-review path. This is not generic server act authority.

Developer

Opt-in · propose → act after gates

The candidate producer for mods, plugins, integrations, and crash-fix patches. Work is intended to run in bounded scratch with tests, but the Developer is not a production server, credential, SFTP, or publication authority.

Code Reviewer

Observe · read-only

The Development Team’s independent second pair of eyes. It reviews the Developer’s actual diff and artifacts for correctness, compatibility, security, and supply-chain issues. It reports findings and never ships or mutates.

Platform services are not customer agents

These services support the product, but they do not appear as additional customer agents, do not receive trust toggles, and should not be described as extra AI personas:

  • Onboarding & readiness — Account, connection, server registration, role activation, and readiness checks. This is a platform flow, not a seventh agent.
  • Billing & metering — Credits, caps, usage records, ledger entries, and resource accounting are platform services, not a customer persona.
  • Learning curator — A platform service that turns public sources and privacy-scrubbed lessons into reusable knowledge. It is not a customer agent card or a metered agent action.
  • Workspace operations — Lifecycle, health, safety controls, and cleanup for your agent workspace.
  • Build and artifact service — Bounded scratch capacity, CI/build execution, artifact retention, and delivery plumbing where those paths are enabled.
  • Independent verification gates — Deterministic tests and risk-triggered independent checks. Verification is an acceptance stage, not another agent persona.
  • Tectonic Agents Support — Help with the Tectonic Agents product itself, distinct from your player and staff Support role.
Observe, propose, act

Trust is an authority boundary, not a conversational preference. A confirmation can select the target and scope of work; it does not silently grant a capability that the workspace or platform has not provided.

  • Observe — read allowed evidence, retrieve, explain, and report. No mutation or production effect.
  • Propose — draft a plan, diff, candidate, or bounded action for review. A proposal is not a completed change.
  • Act — use a specific account-scoped integration only after role, ownership, trust, metering, and verification gates pass. Missing gates mean unavailable or blocked, never fake success.
Development Team: Developer → Reviewer → independent verification

1. Developer candidate

The Developer creates a bounded, testable candidate and records its target matrix, evidence, and expected outcome.

2. Code Reviewer

The read-only Reviewer independently inspects the actual diff and artifacts. It can return APPROVE, REQUEST-CHANGES, BLOCKED, or NEEDS-INFO, but it cannot ship.

3. Independent verification

A separate deterministic or approved independent verifier re-runs the relevant gates and reads the candidate itself. The same execution path cannot verify its own work.

4. Effect authority and read-back

Only the approved delivery path or owner/pinned authority may cause a production effect, followed by live evidence that the effect occurred.

No extra permanent personas

Architect, Builder, Verifier, Integrator, and Incident Commander are useful workflow stages or escalation labels, not agent cards. DevOps and Modpack are folded into Server Manager. Billing, Onboarding, Tectonic Agents Support, and the learning curator remain platform services. Keeping this line clear avoids duplicate context, ambiguous routing, and accidental authority expansion.

Model choice follows the task

The six roles can use different platform-managed model routes when the account surface supports that choice. Use the customer-safe task-fit labels described in Models & Weights; a model label is not an authority grant.

Next

Models & Weights