Temporary specialists

Überblick

Temporary specialists* are the dynamic, role-based agents of the Dynamic Workforce Engine (DWE)* — the agent engine behind Ottili AI. When you hand Ottili AI a goal (a Mission*), the DWE Manager designs a small team of specialists that move the mission forward. Each specialist is temporary*: it is created per mission, works toward exactly one role and one goal, and ends when the mission completes.

Temporary specialists are live (Live)* — publicly documented with the maturity status Live*. They are part of the Ottili AI surface and, like the other Ottili AI capabilities, share a common company context, a common credit account and a common audit trail.

This article describes what temporary specialists are, how they are created, what role, goal and tools they carry, what they may and may not do, how their lifecycle is bounded, and how they are embedded in Ottili ONE.

What temporary specialists are

A temporary specialist is not a permanent, named user account and not a rigid bot profile. It is a dynamic unit of work* generated per mission from the DWE Manager's plan:

• Role-based* — each specialist has exactly one role (for example "German B2B SaaS Google Ads Specialist" or "Local SME Sales Outreach Specialist"), never a vague label like "Marketing Agent".
• Goal-oriented* — each specialist has exactly one goal and a defined output_schema (the JSON keys it must return).
• Temporary* — it exists only for the duration of the mission and is terminated when the mission completes.
• Company-scoped* — each specialist is bound to exactly one company (company_id).

The DWE decomposes the mission into units of work and assigns those units to the specialists. The partial results are merged into the mission's goal.

How a specialist is created

When you hand over a mission, the Dynamic Workforce Engine (DWE)* takes over:

1. Decompose the goal* — the mission is split into manageable units of work.

2. Design the team* — the DWE Manager designs a small team of temporary specialists* (at most 8, preferably fewer). Duplicate roles are avoided.

3. Generate the specialist* — each specialist is generated with role, goal, context, allowed tools, constraints, budget, output_schema, termination conditions and a maximum iteration count, and persisted in a company-scoped way.

4. Call tools* — specialists can call tools to read and modify your data.

5. Merge results* — the partial results are merged into the mission's goal.

On the backend, the SpecialistFactoryService generates the specialists bound to mission_id and company_id, with an idempotency key and limit resolution. Through the Unified API the specialists are listable under /api/v1/ai/dwe/missions/{mission_id}/specialists and generatable via /api/v1/ai/dwe/missions/{mission_id}/specialists/generate.

Role, goal and tools

Every temporary specialist carries a clear, canonical contract:

• Role* — specific and situational, never generic.
• Goal* — a single, clearly bounded task.
• Context* — the information relevant to the task.
• Allowed tools* (allowed_tools) — only what the specialist truly needs.
• Tool effects* (tool_effects) — every tool is mapped to a canonical effect class.
• Constraints* (constraints) — what the specialist must not do.
• Budget* — cost ceilings.
• Output schema* (output_schema) — the JSON keys that must be returned.
• Termination conditions* (termination_conditions) and maximum iterations* (default: 2).

Which models power the specialists is not something you pick yourself: adaptive routing (Ottili Auto)* automatically distributes each request to the right model — everyday work to Ottili Vale*, demanding work to Ottili Cairn*.

What specialists may and may not do

Temporary specialists operate inside a single company tenant*. They never fabricate company data — if data is missing, the specialist lists it under unknowns.

Specialists do not execute external or write actions themselves*. If an action is needed (send email, publish, spend money, update a customer, post to social, start an automation), it is described under suggested_actions so a human can approve it.

Every tool is mapped to a canonical effect class*:

• Auto-executable (within context)*: read_only, dry_run, simulation, internal_write, draft_write, business_document.
• Approval-required*: external_action, external_publication, money_action, destructive_action — critical, external effect waits for approval before it acts outside the company context.
• Forbidden for temporary specialists*: forbidden and admin_action — a specialist must never self-declare these effects; they are escalated, not silently accepted.

Approvals are enforced through Ottili Console* and Ottili Core*.

Lifecycle and limits

Temporary specialists are deliberately bounded:

• Limited count* — the Manager generates at most 8 specialists, preferably fewer.
• One role, one goal* — no generic multi-purpose agents.
• Termination* — termination conditions and a maximum iteration count (default 2) bound the runtime.
• Tenant scope* — every persisted row is bound to a company; a completed mission receives no new specialists.
• Idempotency* — with a stable client key the specialist IDs are deterministic; a replay is a true no-op (no duplicate swarm).

Reusable competency fragments* describe validated building blocks of tools, constraints and a default output schema. A raw spec references fragments by id; the fragments are composed per mission and remain temporary specialists. Adding a new competency is a data change, not a code rewrite — and each fragment is re-validated on use.

Status and availability

Temporary specialists carry the maturity status Live (Live)* from the canonical product-status registry (config/product_truth/ai_feature_status.yaml):

The canonical maturity vocabulary comprises CONCEPT, PLANNED, IN_DEVELOPMENT, PRIVATE_BETA, BETA, ROLLOUT, LIVE, DEPRECATED and DISABLED. For temporary specialists the current capabilities are LIVE; Ottili Spire* is a reserved flagship model and not yet available*, Memory* is planned (PLANNED). We do not claim any capability that is not yet verified as live.

How Ottili ONE publicly labels maturity is described in [Understand feature status labels](/docs/understand-feature-status-labels).

Embedded in Ottili ONE

Temporary specialists are natively anchored in Ottili ONE. They share with the other Ottili surfaces:

• one login* (One Login)
• one company context* (every specialist belongs to exactly one company, company_id)
• one credit account*
• one audit trail*

That means: a specialist always runs inside your company; every action is resolved to a single company and logged through Ottili Core Audit*. The same mechanism powers Ottili Coder, Ottili LD3 and other surfaces from your company outward. The shared account structure is described in [What is Ottili ONE?](/docs/what-is-ottili-one).

Related articles

• [Dynamic Workforce Engine](/docs/dynamic-workforce-engine)
• [Chat and agent modes](/docs/chat-and-agent-modes)
• [Ottili AI](/docs/ottili-ai)
• [Understand feature status labels](/docs/understand-feature-status-labels)
• [What is Ottili ONE?](/docs/what-is-ottili-one)
• [Understand plans and credits](/docs/understand-plans-and-credits)