Skip to content
Customer Docs

The Agent Team

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

Exactly six tenant roles

These are the only customer-facing roles that belong in a tenant’s agent team. Each role runs inside the tenant boundary, is subject to the platform’s metering and trust rules, and must fail closed when its evidence or effector path is missing.

Orchestrator

Observe / propose

The tenant runtime’s main loop. It classifies requests, routes to a specialist, owns tenant memory and skills, and schedules bounded background work. It has no direct production effector and cannot self-approve a change.

Server Manager

Propose; act only when gated

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

Support / RAG

Observe

A read-only support specialist grounded in your tenant’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 tenant agents

These services may be important to the product, but they do not appear as additional customer agents, do not receive tenant trust toggles, and should not be described as extra LLM personas:

  • Onboarding & readiness — Account, tenant, 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 control-plane services, not a customer persona.
  • Researcher / knowledge curator — A platform-only curator for public sources and scrubbed queue candidates. It is not provisioned into a tenant home and is not a tenant-metered agent action.
  • Runtime supervisor — Lifecycle, health, leases, kill switches, and cleanup for tenant runtimes.
  • 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. A verifier is an acceptance stage, not a permanent tenant profile.
  • Tecton Support — Help with the Tecton product itself, distinct from your tenant’s player/staff Support / RAG 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 an effector that the runtime 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, tenant-scoped effector 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 tenant agent cards. DevOps and Modpack are folded into Server Manager. Billing, Onboarding, Tecton Support, and the Researcher 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