AI worker team

Built-in AI workers

The default Kaidera roles customers will see first: product intake, coordination, implementation, QA, knowledge, and review support.

Public draft for dev reviewLast verified 2026-05-22

Created from Phase 2 docs inventory and current Kaidera role model.

Why built-in AI workers exist

Built-in AI workers give projects a starting team. Instead of asking a user to design every role from scratch, Kaidera starts with a proven pattern for scoping, coordination, implementation, quality, memory, and documentation.

Common roles

The exact names and availability can vary by plan, but the pattern is consistent: one role helps clarify the product goal, one coordinates progress, specialist roles execute work, QA checks evidence, and knowledge roles preserve project context.

  • Keith: product intake, scoping, and customer goal clarification.
  • PROMI: project coordination, handoffs, heartbeat, and review readiness.
  • Sophi: backend, systems, and platform work.
  • Marv: frontend, interface, and product experience work.
  • Sage: knowledge, documentation, and memory support.
  • Sam: QA, test planning, and verification evidence.

How users should think about roles

A role is an ownership lane, not a personality gimmick. Users should ask which role owns the next useful action: clarify requirements, coordinate work, build, test, document, review, or preserve knowledge.

Plan differences

The available team can vary by customer plan and enterprise configuration. Starter paths may use a smaller team, while larger enterprise setups can have more specialised roles and customer-specific workers.

When to use Keith

Use Keith-style product intake when the project needs clearer goals, requirements, user stories, success criteria, or scope boundaries before implementation begins.

When to use PROMI

Use PROMI-style coordination when the project needs routing, handoffs, heartbeat checks, progress recovery, review packages, or a safe next step after work pauses.

When to use QA support

Use QA support when work needs acceptance checks, test planning, screenshot review, route checks, risk notes, or evidence before a user approves a gate.

How to use this page

Use the built-in worker guide to understand who owns what before asking for changes. If a request crosses multiple roles, PROMI should help split it into safer work packets.

When to create a custom AI worker

Create a custom AI worker when the built-in roles are not specific enough for a recurring business function, domain, compliance workflow, support queue, research process, or operational review pattern.

What to avoid

Do not treat every task as needing every worker. The safest work is usually scoped to the smallest useful owner, then handed off when another role is genuinely needed.

Read next

Read Custom AI workers next if you want to create a specialist role for your organisation. Read Workbench if you want to see how active worker tasks appear in a project.

Website context

Connect this guide back to the product story

The technology docs map links this page to the public technology narrative and helps buyers move from a capability overview into the right operating guide.

Open technology docs map →