Agent Architecture — Mountain Camp 2027¶

Draft — March 15, 2026

Overview¶

Seven agents supporting the DMC27 organizing team. Two are infrastructure (Knowledge, CRM) that serve the others. One is a router (Orchestrator). Four are domain agents that do the actual work.

                    ┌──────────────┐
                    │ Orchestrator │
                    └──────┬───────┘
           ┌───────┬───────┼───────┬────────┐
           ▼       ▼       ▼       ▼        ▼
      ┌─────────┐ ┌────┐ ┌────┐ ┌─────┐ ┌─────┐
      │ Visitor  │ │Out-│ │Spo-│ │Local│ │  …  │
      │Experience│ │reach│ │nsor│ │Expert│ │     │
      └────┬─────┘ └──┬─┘ └──┬─┘ └──┬──┘ └─────┘
           │       ┌──┴──────┴──┐   │
           │       │    CRM     │   │
           │       └────────────┘   │
           └───────┬────────────────┘
              ┌────┴─────┐
              │Knowledge │
              └──────────┘

All agents operate under the human-in-the-loop rules defined in docs/about/roles.md. Nothing gets published, sent, or committed without human approval.

1. Orchestrator¶

Goal: Be the single entry point for any question or task about DMC27. Understand the full picture, route work to the right agent, and track what's done.

What it does: - Answers general questions about the conference by consulting Knowledge - Breaks down complex requests into tasks for specialized agents - Tracks progress against docs/planning/action-items.md and docs/timeline.md - Identifies blocked work and surfaces it to the team - Synthesizes outputs from multiple agents into coherent updates

What it knows: - Full repo structure and all planning documents - Which agent owns which domain - Current action items, timeline, and team assignments

What it does NOT do: - Deep research (delegates to Visitor Experience) - Contact management (delegates to CRM) - Draft external messages (delegates to Outreach) - Financial decisions (delegates to Sponsoring, human approves)

Key inputs: User questions, action-items.md, timeline.md Key outputs: Routed tasks, status summaries, identified gaps Human-in-the-loop: Flags strategic decisions, budget commitments, and timeline changes for human sign-off

Maps to cluster: Lead & Coordination

2. Visitor Experience¶

Goal: Understand who comes to Mountain Camp and why, then design the journey that turns interest into attendance into contribution.

What it does:

Research side: - Analyze the target audience using existing personas and feedback data - Monitor trends in the Drupal ecosystem, open source, AI, and data sovereignty - Identify topics of interest for sessions, workshops, and keynotes - Benchmark against comparable events (DrupalCon, FOSDEM, other community camps) - Generate audience insights that inform program and marketing decisions

Design side: - Define and maintain the visitor journey from first awareness to post-event engagement - Map key touchpoints (discovery, consideration, registration, arrival, experience, follow-up) - Align touchpoints with the marketing funnel (awareness → interest → decision → action → advocacy) - Ensure the journey reflects DMC values: personal invitation, radical welcome, "makers not takers" - Recommend program structure changes based on journey gaps

What it knows: - docs/marketing/personas.md and docs/marketing/target-audience.md - docs/feedback/feedback-analysis.md (four editions of attendee feedback) - docs/about/vision.md - docs/program/overview.md - ../marketing/communication-strategy.md (personal invitation approach, personas)

Key inputs: Feedback data, persona definitions, trend research, program structure Key outputs: Audience insights, trend reports, visitor journey map, touchpoint recommendations, program input Depends on: Knowledge (historical data), feeds into Outreach (messaging), Program decisions

Maps to cluster: Cross-cutting (Marketing & Web + Program & Content)

3. CRM¶

Goal: Maintain a single, shared contact database that both Outreach and Sponsoring use. Prevent duplicate lists and ensure every contact has clear segmentation.

What it does: - Maintain a structured contact list with segments (speakers, sponsors, attendees, press, partners, community contacts) - Track contact status per segment (not contacted / contacted / interested / confirmed / declined) - Support the personal invitation strategy: flag contacts who should get one-to-one outreach vs. targeted campaigns - Provide contact data to Outreach for messaging and to Sponsoring for sponsor management - Track which persona each contact maps to (from docs/marketing/personas.md) - Log interactions and next actions per contact

What it knows: - Speaker wishlist from docs/program/speakers.md - Partnership targets from checkout notes - Past attendee data (when available from Google Drive / Pretix) - Sponsor history (when available)

What it does NOT do: - Draft messages (that's Outreach) - Negotiate packages (that's Sponsoring) - Decide who to contact (humans decide strategy; CRM executes segmentation)

Key inputs: Contact additions from team members, interaction logs Key outputs: Segmented contact lists, status dashboards, next-action reminders Human-in-the-loop: Adding contacts to "one-to-one personal invitation" segment requires human decision

Maps to cluster: Infrastructure — serves Marketing & Web + Revenue

4. Outreach¶

Goal: Put the marketing funnel and personal invitation strategy into practice. Create and send the right message to the right person at the right time.

What it does: - Draft personalized invitations based on the communication strategy and persona mapping - Draft social media posts, newsletter content, and campaign copy - Execute the "look who's coming" social proof strategy - Draft testimonial outreach messages - Coordinate timing with docs/timeline.md milestones (CFP open, early bird, speaker announcements) - Draft media partner outreach (TheDropTimes, Republic, etc.) - Draft press materials when announcements are confirmed

What it knows: - communication-strategy.md (personal invitation approach) - docs/marketing/roadmap.md (campaign timeline) - docs/timeline.md (milestone timing) - Visitor journey and touchpoints (from Visitor Experience) - Contact segments (from CRM)

What it does NOT do: - Decide who to contact (CRM provides the list, humans approve) - Send anything without human approval - Manage sponsor relationships (that's Sponsoring)

Key inputs: CRM segments, visitor journey, timeline milestones, Visitor Experience insights Key outputs: Draft messages (personal invitations, social posts, newsletters, press materials) Human-in-the-loop: ALL external sends require human approval. No exceptions.

Maps to cluster: Marketing & Web

5. Sponsoring¶

Goal: Ensure the conference has sustainable finances through sponsorship packages, ticket pricing, and budget management.

What it does: - Maintain and refine sponsorship packages and prospectus (docs/sponsorship/prospectus.md) - Draft sponsor outreach messages (personalized per sponsor, using CRM data) - Track sponsor pipeline: prospect → contacted → interested → committed → paid - Draft budget scenarios based on confirmed vs. projected sponsorship and ticket revenue - Propose ticket tier pricing using docs/about/budget.md and comparable event benchmarks - Prepare sponsor fulfillment reports post-event

What it knows: - docs/sponsorship/prospectus.md - docs/about/budget.md - docs/timeline.md (sponsor-relevant milestones) - Sponsor contacts and status (from CRM) - Historical sponsor data (from Knowledge / Google Drive)

What it does NOT do: - Send sponsor communications without human approval - Make financial commitments or payments - Negotiate — humans own all sponsor relationships

Key inputs: CRM sponsor segment, budget data, prospectus, timeline Key outputs: Draft outreach, budget projections, fulfillment reports, package recommendations Human-in-the-loop: All sponsor communications, all financial decisions, all package changes

Maps to cluster: Revenue

6. Local Expert¶

Goal: Make sure visitors know everything about Davos and have an excellent experience beyond the sessions. Be the bridge to local contact Ursin for anything that needs confirmation on the ground.

What it does: - Maintain and update the attendee guide: travel, accommodation, packing tips, local info - Research and propose social events (fondue, skiing, sledding, torch walks, etc.) - Coordinate with Ursin for venue logistics, local supplier contacts, and event confirmations - Provide practical answers: "How do I get from Zurich airport to Davos?", "Where should I stay?", "What's the weather like in March?" - Draft descriptions for social activities and pre-conference options - Track venue setup requirements (rooms, AV, catering) against docs/about/venue.md

What it knows:

• docs/about/venue.md (Davos Congress Centre details)
• Davos tourism information, transport connections, accommodation options
• Pre-conference activity options (skiing at Jakobshorn/Parsenn, etc.)
• Social event history from previous Mountain Camps (via Knowledge)

What it does NOT do: - Book or commit to venues, suppliers, or activities without human approval - Handle anything financial - Make promises to attendees about what will be provided

Key inputs: Venue details, social event ideas, attendee questions, Ursin's input Key outputs: Attendee guide content, social event proposals, venue logistics checklists, answers to visitor questions Human-in-the-loop: All commitments to venues/suppliers. Ursin coordinates directly with team; agent drafts and proposes.

Maps to cluster: Venue & Experience

7. Knowledge¶

Goal: Provide grounded, accurate answers about anything DMC-related by indexing all available sources. Serve as the memory layer for all other agents.

What it does: - Index and search this planning repository (all markdown files) - Index and search Google Drive documents from previous editions - Answer factual questions: "What was the attendance in 2025?", "Who sponsored last year?", "What did feedback say about workshops?" - Provide context to other agents when they need historical data or decisions - Surface relevant past decisions when new ones are being made ("We discussed this in 2024 and decided X")

Sources at launch: 1. This Git repository (all docs/) 2. Google Drive (historical documents, meeting notes, budgets from previous years)

Future sources (not at launch): - Slack history (meeting context, informal decisions) - drupalmountaincamp.ch website content - Pretalx (session submissions, speaker data)

What it does NOT do: - Make decisions or recommendations (it retrieves; other agents reason) - Create new content (it provides facts for other agents to use) - Access sources it hasn't been explicitly connected to

Key inputs: Queries from other agents or from humans directly Key outputs: Retrieved passages with source attribution, factual answers Human-in-the-loop: None needed for retrieval. If Knowledge surfaces conflicting information, it flags the conflict rather than choosing.

Maps to cluster: Infrastructure — serves all clusters

Agent Dependencies¶

Orchestrator
  ├── routes to → Visitor Experience, Outreach, Sponsoring, Local Expert
  ├── reads from → Knowledge, CRM
  └── tracks → action-items.md, timeline.md

Visitor Experience
  ├── reads from → Knowledge (feedback, personas, history)
  └── feeds into → Outreach (journey, messaging angles), Program decisions

CRM
  ├── reads from → Knowledge (historical contacts)
  ├── serves → Outreach (attendee/speaker/press segments)
  └── serves → Sponsoring (sponsor segments)

Outreach
  ├── reads from → CRM (contacts), Visitor Experience (journey), Knowledge (history)
  └── produces → draft messages for human approval

Sponsoring
  ├── reads from → CRM (sponsors), Knowledge (history, budgets)
  └── produces → draft outreach, budget projections for human approval

Local Expert
  ├── reads from → Knowledge (venue history, past events)
  └── produces → attendee guide, event proposals for human approval

Knowledge
  └── serves → all agents (retrieval, grounding)

Phasing¶

Recommended build order based on value and dependency:

Infrastructure & Integrations¶

Contact management (CRM agent)¶

Primary system: Campaign Monitor — existing tool for contact storage and email campaigns.

Additional contact sources: - Google Drive lists (historical attendee/sponsor lists across editions) - Pretalx (speaker submissions, session data, speaker contacts) - Speaker wishlist in docs/program/speakers.md

The CRM agent treats Campaign Monitor as the source of truth for contacts. Google Drive and Pretalx are read-only sources for enrichment and historical context. The agent proposes changes; humans execute in Campaign Monitor.

Knowledge sources¶

At launch (Phase 1): 1. This Git repository — github.com/drupal-switzerland/dmc27 2. Google Drive — Drupal Switzerland shared drive and per-edition folders: - Drupal Switzerland shared drive - 2017 - 2019 - 2022 - 2024 - 2025 - 2027

Future additions: - Slack workspace history - drupalmountaincamp.ch website content - Pretalx session/speaker data

Communication channels¶

Ursin (local contact): Slack or email. Local Expert agent drafts messages for Ursin; human team member sends via Slack DM or email.

Shared state: GitHub repository¶

The repository (github.com/drupal-switzerland/dmc27) is the shared state for all agents: - Documents and plans: docs/ directory (markdown files) - Task management: GitHub Issues — the Orchestrator creates, assigns, and tracks issues - Drafts: Agents commit drafts to the repo (in appropriate directories) for human review - Decisions: Captured in planning docs and meeting notes, synced to action-items.md

GitHub Issues are the confirmed task backbone (agreed planning weekend checkout, March 2026). The Orchestrator creates issues, assigns them to the right agent or human, labels them by domain (outreach, sponsoring, local, program, etc.), and tracks completion. A Kanban board view in GitHub Projects gives the team a visual status overview. This keeps everything visible without needing a separate project management tool.

Agent–Human Pairings¶

Each agent has a designated human team member who validates its work, provides direction, and approves external actions. Based on the working groups:

Miro's group assignment is TBD (see docs/planning/working-groups.md). Once assigned, he can pair with the relevant agent.

Sinduri (Logistics) works closely with the Local Expert agent for venue and logistics planning.

Slack Integration¶

Approach: One Slack bot as the unified interface. Team members interact with agents through Slack, with the bot routing to the right agent.

How it works¶

Team member in Slack
        │
        ▼
  ┌───────────┐
  │ DMC27 Bot │  ← single Slack bot
  └─────┬─────┘
        │
        ▼
  ┌──────────────┐
  │ Orchestrator │  ← routes to the right agent
  └──────────────┘
        │
   ┌────┼────┬────┬────┬────┐
   ▼    ▼    ▼    ▼    ▼    ▼
  VX  CRM  Out  Spo  Loc  Know

Invocation patterns: - General questions → Bot routes through Orchestrator: "What's the status of speaker outreach?" - Direct agent calls → Prefix with agent name: @dmc27 outreach draft a social post for CFP opening - Notifications → Bot posts to relevant channels when issues are created, deadlines approach, or drafts need review

Channels: - #dmc27-general — Orchestrator answers, cross-cutting updates - #dmc27-program — Visitor Experience and program-related agent output - #dmc27-marketing — Outreach and CRM agent output - #dmc27-sponsors — Sponsoring agent output - #dmc27-logistics — Local Expert agent output

Phase 1 (minimal): Bot responds to messages in one channel, routes through Orchestrator, reads from repo + Knowledge. No write actions — draft output only.

Phase 2: Bot can create GitHub Issues (confirmed task management tool), post to specific channels, and tag human leads for approval.

Phase 3: Bot triggers on timeline events (approaching deadlines), proactively surfaces action items and blocked work.

Phasing (revised)¶

Open Questions (remaining)¶

1. Campaign Monitor API access: Does the team have API credentials for Campaign Monitor, or should the CRM agent work through exported lists initially?
2. Google Drive auth: Which Google account has access to all edition folders? Needed for Knowledge agent indexing.
3. Slack workspace: Which Slack workspace is the bot deployed to? The Drupal Switzerland workspace or a dedicated DMC planning workspace?
4. GitHub permissions: Should the bot/agents have write access to the repo (create issues, commit drafts), or should a human always push?

This document defines agent goals, scope, and infrastructure. Implementation approach (skills, Agent SDK, MCP) to be decided based on phasing priorities.

Related: AGENTS.md (repo-level agent instructions), about/roles.md (cluster-based boundaries and 5 accountability clusters).