A leader who completes the Foundations programme leaves with an AI agent that is already productive from Day 1 — not a blank-slate chatbot, but a configured, role-aware executive-level intelligence.

• Coaches / Programme Leads — run sessions, monitor progress, manage participant cohorts, and deliver configurations.
• Moonbase Admins — manage the global challenge library, client onboarding, and role templates.
• Client Leads — oversee their organisation's cohorts and participant outcomes.
• Participants — access the AI Interview at /interview (no admin login required).

Six core entities form the data backbone of the platform. They describe who the brand belongs to (BrandEntry → Client), who runs the programme (Coach → Cohort), who attends (Participant → Cohort), and what the cohort works through (CohortAgenda → Cohort). Every entity below carries explicit reference fields that wire it to its neighbours.

The dashboard is the command overview. It is read-only and updates on load.

• Active Cohorts ring metric — shows cohorts with status active, week1_enablement, or week2_enablement.
• Participants in Progress — count of participants with programme or ongoing_coaching profile status.
• Configurations Generated — total active agent configuration records.
• Client Overview table — lists all clients with cohort count, participant count, and status badge. Click a client name to navigate to their cohort view.
• Activity Feed — last 30 events: interviews completed, milestones reached, configs generated, participants added.

Use Clients to manage the organisations enrolled in the programme.

• Click ADD CLIENT to create a new organisation record. Name is required. Industry, primary contact, and AI agent assignment are recommended.
• Set the AI Agent field to onboarding_interview to enable the AI-facilitated interview for that client's participants.
• Status options: active, on_track, at_risk, complete. Update this manually to reflect programme health.
• The Client Lead field links to a platform user account responsible for this client.

Cohorts group participants and track the programme lifecycle stage.

• Create a cohort linked to a client. Set a programme date (the date of the foundational programme day).
• Advance cohort status manually as sessions progress: scheduled → active → week1_enablement → week2_enablement → complete.
• Participant counts are displayed per cohort to give a quick size reference.

The participant list is the operational hub for facilitators during a live programme.

• Use the filter pills at the top to isolate participants by interview status: NOT STARTED, IN PROGRESS, or COMPLETE.
• The list auto-sorts with NOT STARTED (red) at the top — these are the participants who need a nudge first.
• Click a participant's name to open their full detail page.
• The detail page has five tabs: Overview (key fields), Interview (manual stage entry), Config (generation and copy), Milestones (click to toggle), and Action Plan (30-day goals).

Important: The interview page at /interview is accessible without an admin login. Share this URL directly with participants. Each session starts fresh by default. Coaches use /facilitator/interview-links to send edit links for existing sessions.

During the interview, a 5-node progress bar displays below the header. Each node shows: completed (cyan checkmark), active (glowing solid), or pending (dimmed). The tracker auto-advances based on the AI agent's message content — no manual input required.

If a participant needs to revisit their interview (e.g. after a review session), a coach uses /facilitator/interview-links to generate a direct edit link that opens their specific session. The interview header shows an amber EDIT MODE badge when in this state. The initial trigger message is automatically hidden from the conversation display.

Coaches can also enter or update interview data manually via a participant's detail page (Interview tab). Each stage has form fields with a COMPLETE STAGE option and a SAVE DRAFT option. Completing all 5 stages marks the interview as complete and sets config_status to pending, ready for configuration generation.

Once a participant's interview status is COMPLETE, navigate to their detail page, open the Config tab, and click GENERATE AGENT CONFIGURATION. This assembles the configuration script from all five interview stages and saves it as a permanent record.

• Identity Block — name, title, organisation, industry, reporting line, team structure.
• Core Instructions — working day focus areas and time allocation from Stage 2.
• Capabilities — the top 3 priority handoffs and key pain points from Stage 3.
• Tools and Context — systems, stakeholders, compliance constraints from Stage 4.
• Guardrails — confidentiality boundaries and escalation rules from Stages 4 and 5.
• Tone and Communication — communication style and trust factors from Stage 5.
• First Week Priorities — the immediate focus areas drawn from Stages 2 and 3.

Click COPY on the Config tab to copy the full script to clipboard. This text is then pasted into the AI agent's system instructions. The configuration can be regenerated at any time. Coach notes and week 1/2 review notes fields are available for Day 3 and enablement use.

• Global challenges belong to the Moonbase library and are available to all clients.
• Org-scoped challenges are specific to one client.
• Complexity tiers: Quick Win (fast, low-barrier), Standard (core programme activities), Stretch (deeper application challenges).
• Challenges can be assigned to all participants, a specific cohort, or an individual participant.

Challenges with client set to Template appear as reusable library items. Use COPY TEMPLATES TO CLIENT to clone the full template library to a specific client and optionally assign them directly to a cohort. This is the recommended fast-setup path for a new client.

Each challenge has two supporting fields: Why This Matters explains the developmental rationale, and Design Logic explains the thinking behind how the challenge is structured. These are visible below each row in the challenge list and guide facilitators in contextualising tasks for participants.

If a challenge involves an AI agent interaction, enable the INVOLVES AI AGENT checkbox and enter the agent name. A LAUNCH button appears in the challenge list, linking directly to the agent's WhatsApp connection URL.

• Type banner — a Happy AI yellow header showing the assignment type (Task, Challenge, Skill, Reference), the assignment title, and the close control.
• Time Allocated — the assignment's estimated duration, shown in the header on the right. Depending on the cohort's Instruction Board time setting it runs as a live countdown (with start/pause/reset controls) or simply displays the allocated minutes.
• Code and title — the assignment's code (e.g. CH-001) and name.
• Description — what the assignment asks the participant to do.
• Prerequisites — any tools or setup required before starting, shown as chips; displays "None required" when empty.
• Instructions — the assignment's Design Logic, presented as the step-by-step instructions.
• Files available for download — reference materials attached to the assignment (uploaded files with a Download button, external links with an Open button).

An assignment can carry an Instruction Board image. It is set on the Assignment Manager form using the Instruction Board Image dropdown, which is populated from files tagged Used For: Instruction in the File Manager (Settings). Upload the image there first, set its USE FOR value to Instruction, then select it on the assignment.

When an image is set, the participant's Instruction Board widens to show the image in a panel directly to the right of the board content — at the same height and width as the board itself, under the same window header. Assignments without an image keep the standard single-board layout.

• Display panel size — the image panel renders at roughly 620 × 700 px on a desktop (the window widens to about 1240 px, split into two equal columns; the height stretches to match the board content and is capped by the viewport).
• Recommended source image — a square (1:1) image at about 1240 × 1240 px. This is 2× the display size, so it stays sharp on high-resolution screens.
• Fitting behaviour — the whole image is always shown: it is scaled down to fit inside the panel (contain) with no cropping, centred against a paper background.
• Aspect ratio still matters — the panel is roughly square, so a square (1:1) image fills it edge to edge. Very tall or very wide images will show the whole image but leave vertical or horizontal letterboxing space in the panel.

Automated evaluation. When a goal is created — or when its name or baseline changes — the evaluateGoal3P backend function runs automatically. It scores each pillar, assigns primary and secondary P classifications, and drafts a buyer-vocabulary pitch for the matching persona. Admins can then review, adjust the checklist, and approve; participants can refine the pitch wording on their own workbench.

Each pillar is scored out of 5. A score of 4 or 5 qualifies that P as a primary or secondary classification. The card displays a running total out of 15 across all three pillars.

A critical distinction the framework enforces: the assistant configuration itself is infrastructure, not an automation. "We configured your personalised AI agent" is a setup event — it doesn't do a task, it enables the tasks the participant later runs through it. Forcing a P onto the configuration event would be exactly the vague-value-language the framework exists to catch.

Once a goal is evaluated, it enters a coach review workflow tracked by the p_classification_status field:

• not_classified — no evaluation has run yet (default for legacy goals).
• pending_review — the AI has produced a classification; an admin reviews the checklist, pitch, and prove metric.
• approved — the admin has validated the classification and stamped it with their name and timestamp.
• needs_revision — the classification was rejected and the goal should be re-evaluated or re-edited before approval.

Admins can fully edit the checklist (toggle any of the 15 items), the primary/secondary P assignment, the pitch persona and text, and the prove metric. Participants on the public workbench can refine the pitch paragraph in their own words — but cannot change the checklist or classification, so the admin's validated scoring stays intact.

For each classified goal, the evaluation drafts a one-paragraph buyer-vocabulary pitch written for the persona that matches the primary P:

• CFO (primary P = Prove) — framed in cost, baseline, and measured outcomes.
• HR Leader (primary P = Protect) — framed in named risks, recurrence, and human oversight.
• Department Head (primary P = Produce) — framed in freed time, task removal, and output quality.

The pitch ensures every goal can be communicated in the language of the stakeholder who would sponsor it — turning an internal task into a fundable, defensible value proposition.

Only participants who have an existing interview record appear in this list. For each participant, two actions are available:

• COPY — copies the edit link to clipboard. Paste it into a message, Slack, or email manually.
• EMAIL — sends a formatted email to the participant's registered email address (personal or company) with the edit link embedded. Uses the platform's built-in email system.

Note: Edit links reference the participant's OnboardingInterview record ID. If the interview record is deleted, the link will no longer work. Participants who have not yet started an interview do not appear on this page — they should be directed to /interview to begin fresh.

When to use: Enable Shields Up for high-stakes sessions, sensitive client cohorts, or any time you want to guarantee only the participants in the room can access the platform. It is a manual toggle — it stays on until you turn it off.

When Shields Up is active and a participant opens their workbench link, they are shown a SHIELDS UP — COHORT KEY REQUIRED screen instead of their workbench. They must type the cohort key into the input field and click VERIFY KEY. An incorrect key shows an inline error and lets them retry. A correct key proceeds to the workbench.

• Generate New Key — click the button below the key field to rotate the key instantly. All participants who were already in the workbench remain; new arrivals must use the new key.
• Manual Edit — you can type a custom key directly into the field. Changes save on blur.
• Turn Off — toggling Shields Up off removes the key requirement immediately. Participants return to standard access-link-only entry.

Lock vs. Shields Up: The Lock toggle blocks all participant access entirely (a holding screen). Shields Up does not block access — it adds a verification step. Lock takes priority: if both are on, participants see the locked screen, not the key prompt.

Structure: https://<brand-subdomain>/c/<cohort.url_code>/p/<participant.url_code> for participants, and /c/<cohort.url_code>/coach for coaches. When Shields Up is active, append /s/<frequency>.

The primary participant dashboard — challenges, goals, agent, and milestones.

Both codes are validated by the UrlCodeGuard before the workbench loads. The cohort code resolves the cohort, client, and brand; the participant code resolves the individual record.

The standalone AI onboarding interview — no admin login required. This is the link shared with participants to begin or resume their 5-stage interview.

The same cohort + participant codes are validated first. The interview page loads the participant and cohort context directly, skipping the workbench shell.

The coach-facing roster and live chat dashboard for a cohort. Coaches also need their coach console PIN on entry.

No participant code is required — the cohort code resolves the cohort, client, and brand. The PIN is matched server-side against an active coach's coach_console_pin.

The branded sign-in / access page for participants who need to authenticate rather than use a coded link.

When Shields Up is active, a cohort frequency segment is appended to any participant URL as the verbal second factor.

The shieldFrequency is a 10-character cohort key configured in Front Door Controls. Workbench and interview links both accept the suffix; the coach console does not use it (coaches use their PIN instead).

The <host> is determined per client from their linked BrandEntry:

• Standard — the brand's application_subdomain (e.g. acme-app.mitscommand.com).
• Vanity — the brand's vanity_subdomain (e.g. acme.mitscommand.com), used when the client's url_mode is set to vanity.

The Cohorts page builds and copies the full URL pattern for each cohort, substituting the correct host and cohort code while leaving the participant code as a placeholder.

The moment a conversation is created, the platform fetches the participant's full record and their ParticipantBaseline and injects the relevant fields into the agent's opening context. The agent receives:

• From Participant: full name, job title, role description, role capabilities & skills, and reporting line (reports-to title).
• From ParticipantBaseline: role context notes, current AI usage habits, the real-work task the participant brought to their Foundations day, friction points and pain points surfaced during the interview, and any topics flagged as needing coach follow-up.
• From the Challenge: challenge ID and title, so the agent frames its coaching around the specific task in focus.

Previously, the agent only knew the participant's name and ID. Coaches had to manually re-explain the participant's situation, pain points, and role before the AI could give relevant advice. Now the agent starts every session already aware of the participant's professional context, their stated friction points, and what they are working on — so its recommendations are immediately specific and actionable.

Example: If a participant's baseline notes mention friction with manual status reporting, and the challenge is about automating a weekly update, the agent can proactively connect the two: "I see from your interview that manual status updates are a major friction point — this challenge is a direct opportunity to address that."

The AI-assisted chat panel is available wherever a coach interacts with an agent-linked challenge or participant session. The context injection happens automatically — there is no setup or manual briefing required from the coach.

The flow: Goal → Whiteboard the automation left-to-right → capture enough to populate the 5-box Skill → package the Skill's files with ParticipantDeliveryPackage.

Every whiteboard belongs to a Goal — the value outcome the participant is chasing. From the Workbench, the participant creates a whiteboard and links it to a Goal. The whiteboard then becomes the working surface for designing the single automation that satisfies that goal. A participant can filter their whiteboards by Goal and keep one canvas per Goal.

The canvas reads left to right, mirroring how work actually flows. Participants drag boxes (steps), text (notes and questions), and headers onto the canvas, then connect them with numbered arrows. The aim is to capture the full journey: where data starts, what happens to it, and where it lands.

• Boxes — each step or handoff in the process. Carries an action label, a title, freeform content, tags, and an optional attached file from My Files.
• Text — supporting notes, approvals, or open questions, referencing boxes by letter (A, B, C…) and arrows by line number (1, 3, 5…).
• Arrows — the numbered flow between steps.
• Headers — section structure (H1 / H2 / H3) to organise the canvas. H1 is a bold caps title; H2 renders handwritten with a teal underline; H3 is a colored icon + label card whose color is derived from its group icon or manually overridden.

The whiteboard is not the end product — it is the discovery surface. The participant's objective is to sketch enough real detail that the canvas can be translated into a ParticipantSkill, which is itself a five-box build:

• Box 1 — Name & Role — the one job this skill does and its scope.
• Box 2 — Job Description — tone, format, priority logic, and step sequence (the core operating instructions).
• Box 3 — Reference Binder — the named sources the skill reads from.
• Box 4 — House Rules — off-limits, check-first, always-do, and escalation paths.
• Box 5 — Toolkit — the allowed actions and connectors the skill may use.

Running the Completeness Check (evaluateWhiteboardCompleteness) compares the canvas against the five-box standard and surfaces exactly what is still missing — shown in the Draw This Next panel — so the participant knows what to add before the skill can be authored. An AI Narrative (generateWhiteboardNarrative) can also be generated to summarise the end-to-end process from the boxes, actions, tags, and arrows.

The canvas is structured by the Workbox Prompts Lookup list (list_name: workbox_prompts), configured in Settings. Each entry is a unit of work that can be assigned to a box or text object and supplies the prompt fields the participant fills in to capture attributable design detail.

• Action labels — the value is the stored action/text-type a participant assigns to an object. Each entry carries a display label, a functional group (source, destination, process, instructions, reference, approval, house_rules…), an optional icon resolved against the group icon set, and an object filter (box / text / all) controlling which options appear for the selected object type. The chosen action drives the darker action header rendered on the object, including the group icon.
• Diagram mode — every entry has a mode (skill or normal). The whiteboard's own mode filters which entries surface: skill optimises the prompts for a five-box skill build; normal surfaces general diagramming prompts. Change the whiteboard's mode in the Canvas Inspector and the available actions follow.
• Prompt parsing — the box_prompts field holds a comma-separated list of prompts (commas inside [] or do not split). Each prompt may carry an optional {attribute_key} (the storage key for the captured value; if omitted the prompt label is used) and optional [bracketed help text] shown as in-field guidance. The first prompt becomes the object's Title (collected in the yellow title strip); the remaining prompts become attribute capture fields in the Object Inspector, each stored on the object's attributes keyed by attribute_key so captured answers persist alongside the box.

A whiteboard can be started from a template and rendered over a custom background image. Both are managed from the Canvas Inspector (the side panel shown when no object is selected).

• Whiteboard Templates (WhiteboardTemplate) — admin-established full starter canvases (boxes, headers, arrows, mode, narrative, and File Away groups). Any participant can Apply a template to load its contents onto the current whiteboard. Admins can Save as template from inside a whiteboard to publish the current canvas as a reusable template.
• Canvas Backgrounds (WhiteboardBackground) — optional image rendered behind the dotted canvas. Template backgrounds (source: template) are admin-established and available to all users; user backgrounds (source: user) are saved by an individual participant for their own use. The selected background's file_url is copied onto the whiteboard as background_url; clearing it returns the canvas to the default dotted grid.

When the five-box Skill is complete and coach-approved, its constituent files are packaged using the ParticipantDeliveryPackage entity — a participant-scoped, per-file mapping that places each file into the skill's folder structure.

• Folder layout — skill deliveries use the top-level folders root, scripts, references, and assets, mapped from each file's classification_basis (reads_as_prose → references, executes_as_code → scripts, renders_into_output → assets, defines_trigger_logic → root).
• Per-file metadata — each row records the file_name, the uploaded file_url or a link to a ParticipantManagedFile via myfile_url, the file_path inside the package, the produced_by source (Charlie, Claude, the participant, the build pipeline, or the design pipeline), and a lifecycle status (draft → ready → packaged).
• Result — the assembled package produces the skill's SKILL.md and its supporting references, scripts, and assets, ready for delivery.

Where it lives: The Draft a Skill button appears on the participant's Build Skills page and in the Skill Service Bay. Every draft is saved as a real ParticipantSkill record — never just chat history.

• From a Goal — the participant picks one of their workbench goals. If the goal has a linked objective, the draft attaches to it; otherwise an objective is created from the goal and linked automatically.
• From an Objective — the participant picks an existing objective directly, and the draft is filed under that objective alongside its sibling skills.

• Generate — a one-shot pass: the starter reads the goal or objective (plus the participant's role context) and produces a full first-draft skill across all five boxes in a single action. The participant reviews and confirms or corrects it.
• Guided — a coaching conversation: the starter asks targeted questions, one gap at a time, and writes each answer into the matching box as it's given. The participant's own words drive the draft.
• Gap Fill — launched from the completeness check: after a check, every field that is still unconfirmed gets a targeted follow-up question, and the chat works through just those gaps.

Every starter field carries a fill state, so the participant can always see what came from them and what came from AI:

• Unfilled — nothing yet; the box is empty.
• Assumed — AI inferred it (from the goal, objective, or role profile). It needs the participant's confirmation before it counts.
• Confirmed — the participant stated it directly. Only confirmed values count toward readiness.

Fill states are stored per field on the skill record (in starter_state.fill_states), keyed by box and field — e.g. box1.one_job_statement, box3.sources.

The Check runs against the starter's field checklist: required fields that are not yet Confirmed are reported back as gaps, each with a targeted follow-up question. When every required field is confirmed, the check marks the draft Ready to Use — meaning the participant has stated every required decision themselves.

Guided and gap-fill conversations are stored on the skill record as a transcript (starter_state.transcript). Closing the modal mid-conversation is safe — reopening the starter resumes the session exactly where it left off, with fill states and box content intact.

Every starter-drafted skill carries a fixed status boundary note: it is a personal draft that has not been verified, audited, or approved — it is ready to use, adjust, or hand to someone whose judgment the owner trusts. This note is always confirmed-by-default and cannot be authored away.

A starter draft is a real five-box skill: Box 1 (Name & Role), Box 2 (Job Description), Box 3 (Reference Binder), Box 4 (House Rules), and Box 5 (Toolkit) are all authored through the flow, and the resulting record behaves like any other ParticipantSkill — it can be opened in the Skill Service Bay, expanded on the Build Skills page, validated, exported, and linked to a workflow whiteboard. The starter simply makes getting to a complete first draft fast, grounded, and honest about what is assumed versus confirmed.

Trigger: An admin clicks Build Agent Components on a participant record. The function receives a single input — participant_id — and returns a saved ParticipantBuildComponents record with the complete configuration.

The function pulls four categories of source data from the platform database:

All gathered source data is assembled into a single structured prompt sent to the platform's LLM integration (InvokeLLM). The prompt instructs the LLM to act as an expert AI agent architect and produce a configuration that is specific to the participant's role, grounded in real data, and free of generic placeholders.

The prompt includes these source sections:

• Participant Profile — name, title, role description, skills, reporting line, direct reports.
• Client Context — company, industry, description, compliance requirements.
• Associated Agent Role — role code, name, base capabilities, hierarchy links, base template. Or a note that no catalog match was found.
• Associated Enhancements — the full list of merged enhancements (from both the catalog and the participant's own selections), each with its category, key, name, and description.

The LLM is asked to generate four structured output blocks, returned as a single JSON object matching a strict response schema:

• Agent Declaration — internal agent name, one-sentence role statement, assembled identity block, reporting line, upward communication standard, and 2-3 sentences of industry context.
• Agent Behavior — 6-10 capabilities (merged from role base + participant skills), guardrails across the 8-category framework (ESC-, COMM-, FUP-, COMP-, CONF-, AUTH-, BIAS-, FMT-), and knowledge sources with [TO CONNECT] flags for unlinked systems.
• Agent Instructions — exactly 6 instruction modules (each with a title and 2-4 sentence body) covering daily operations, stakeholder communication, decision-making authority, compliance, reporting cadence, and escalation procedures. Plus an assembled core_instructions text block.
• Tone Settings — agent tone, communication style, trust factors, escalation triggers, and always-escalate topics.
• Full Config Script — all four blocks assembled into a single markdown-formatted configuration script, ready to load into an AI agent.

Before writing the record, the function checks for existing builds for this participant. If previous builds exist, the next version number is incremented (max existing version + 1). A unique config_hash is generated in the format HAI_<last-6-of-participant-id>_v<version>_<timestamp>. This hash anchors the build record and supports versioned rebuilds.

The LLM result and metadata are persisted as a new ParticipantBuildComponents record with:

• Identity fields — config_hash, participant_id, product_id (fixed to HAI_AGENT), client_id, cohort_id.
• Match metadata — matched_role_id, matched_role_code, match_method (matched or custom), custom_profile_reason, generation_method (ai_generated), is_custom flag.
• Denormalized display fields — participant_name, job_title, organisation, industry (copied for display/audit even if source records change later).
• Configuration blocks — agent_declaration, agent_behavior, agent_instructions, tone_settings (all as structured JSON objects), and full_config_script (assembled text).
• Lifecycle — status set to draft, version number, generated_date.

The function returns { success: true, build: <record> } on success. Any error returns a 500 with the error message.

Enhancements are the guardrails, compliance constraints, and communication styles that shape the agent. They enter the build from two sources:

This function requires an authenticated admin session. The caller's identity is verified via base44.auth.me() — if no session exists, a 401 is returned. If the user is not an admin, a 403 is returned. There is no public or participant-facing access to this function.

The platform is powered by a set of backend functions — serverless HTTP handlers in base44/functions/. They handle everything the frontend cannot do directly: bypassing RLS for the public workbench, orchestrating multi-step agent builds, reacting to entity events, and serving branded theme scripts. Below they are grouped by purpose, with their access model and key inputs.

Agent Enhancements are the reusable configuration blocks that shape how an agent behaves. Each enhancement has a category, a unique key (prefixed with a category code), a display name, and a description of what it does. When an agent is built, enhancements are resolved and folded into the guardrails, compliance, tone, and behavior blocks of the configuration.

Two layers of access. The MCP server itself authenticates the human via OAuth sign-in. On top of that, each tool enforces its own role-specific credential. So an assistant always acts as a signed-in user and must supply the right code or secret for the tool it is calling.

Participant-facing tools are gated by the same non-guessable URL codes that power the public workbench. An assistant acting for a participant must supply the participant's cohort_code and participant_code.

• validate_access — resolves a participant from cohort_code + participant_code (pass cohort_key only when Shields Up is active). Returns the participant id and context needed for the other tools.
• verify_participant_identity — confirms identity from the same two codes; returns minimal fields.
• get_participant_challenges, get_participant_agent_builds — read a participant's challenges, completions, and agent builds. Each takes participant_id + participant_code.
• manage_participant_chat, manage_participant_notes, manage_participant_goals — list, create, update, or delete the participant's chat, notes, and goals. Each takes participant_id + participant_code.
• generate_participant_role_content — generates a role description (default) or capabilities + enhancement recommendations (capabilities mode) for the participant.

Every participant tool verifies the participant_code against the stored url_code on the participant record; a mismatch returns 403. No participant data is reachable without both codes.

Coach access uses the validate_access tool in coach mode. An assistant acting for a coach supplies cohort_code + coach_pin (omitting participant_code). The PIN is matched against an active coach's coach_console_pin. An incorrect PIN is flagged and no coach context is returned.

Operations tools are the most powerful — they build agent configurations, run the role matchmaker, and generate role descriptions. They require the MCP_OPS secret, stored as an app secret and never shipped to the client.

• build_participant_agent — builds a participant's full agent configuration. Requires participant_id + mcp_ops_secret.
• run_agent_matchmaker — evaluates a role profile (search mode) or a participant's interview (participant mode). Requires mcp_ops_secret.
• generate_role_description — writes a professional role description for a participant. Requires mcp_ops_secret.

Inside each ops function, the secret is checked against process.env.MCP_OPS. A correct secret authorises the call directly. If the secret is absent, the function falls back to the existing admin-session check — so the in-app admin tools keep working unchanged, while an assistant calling via MCP must present the secret.

Beyond the custom tools above, the MCP server auto-exposes every entity (one query_ / create_ / update_ / delete_ tool per entity) and the onboarding interview agent (a message_ tool). These are gated by the signed-in user's row-level security — an operations manager (admin) gets broad access, while other roles see only what their permissions allow. Individual entity and agent tools can be turned off on the app's MCP page without editing code.