AI Boardroom — end-to-end tutorial

Goal

By the end of this tutorial you will have imported the AI Boardroom Scrydon Pack bundle into your tenant, created a fresh instance for the fictional Helios Renewables AG Q1 2026 board meeting, uploaded a realistic eight-document board pack, watched six specialist AI agents produce a consolidated executive briefing, recorded the meeting, and walked the AI-generated minutes through review and approval.

Marc, our fictional company secretary, walks through this on a clean tenant. All entity names, directors, figures, and resolutions in the demo documents are fictional.

Prerequisites

You have a Scrydon deployment with the agentic, ontology, and analytics surfaces enabled. You're signed in as a workspace admin. Set the following env vars in your shell for the import step:

export SCRYDON_URL="https://<your-scrydon-url>"
export ORG_ID="<your-org-id>"               # visible in /settings/organization
export SESSION_COOKIE="$(cat ~/.scrydon/session-cookie)"  # or paste from the browser

Step 1 — Download the pack bundle

The pack is a small (≈ 4 KiB) gzip stream containing pack.json, an ontology/manifest.json (the three Object Types and two Link Types described below), and process-flow/manifest.json. No executable code.

Download ai-boardroom-4.2.0.scrydon-pack.tar.gz

Or from a terminal:

mkdir -p ai-boardroom-tutorial && cd ai-boardroom-tutorial
curl -O https://docs.scrydon.com/static/process-pack-examples/ai-boardroom-4.2.0.scrydon-pack.tar.gz

Step 2 — Inspect the pack (optional but recommended)

Run the SDK inspector to confirm the archive validates against the runtime schema before you upload it. The inspector reads the archive in streaming mode, enforces the same security caps the import endpoint applies (10 MB compressed, 20 MB uncompressed, 400 files, no symlinks, no path traversal), and runs the task-DAG cycle check on the process-flow/ subdir.

bunx @scrydon/sdk-authoring pack inspect ai-boardroom-4.2.0.scrydon-pack.tar.gz

Expected output (abbreviated):

Pack:
  Package:  ai-boardroom@4.2.0
  Contents: ontology@1.0.0, process-flow@1.0.0
  Install order: ontology → process-flow
  ontology: ai-boardroom@1.0.0
  process-flow: ai-boardroom (3 stages)

The ontology subdir declares three Object Types (BoardMeeting, BoardDocument, ActionItem) and two Link Types (DocumentDistributedAt, ActionItemFromMeeting). The process-flow subdir's task and action ontologyContract blocks reference those by slug. When you upload the pack, the importer installs the ontology first, queries the tenant's freshly-installed branch for the resolved class IDs, then rebinds the slugs to those IDs before persisting the flow — all inside one DB transaction.

Step 3 — Upload the pack

POST the archive to your org's pack import endpoint. The response includes the assigned template ID and the slug you'll use in Step 4.

curl -X POST "$SCRYDON_URL/api/packs/import?organizationId=$ORG_ID" \
  -H "Cookie: $SESSION_COOKIE" \
  -F "file=@ai-boardroom-4.2.0.scrydon-pack.tar.gz"

Expected 200 response:

{
  "packageId": "ai-boardroom",
  "version": "4.2.0",
  "bundleHash": "sha256:...",
  "ontology": {
    "branchId": "br_01HF...",
    "alreadyInstalled": false,
    "slugs": {
      "objectTypes": {
        "BoardMeeting": "ot_01HF...",
        "BoardDocument": "ot_01HF...",
        "ActionItem": "ot_01HF..."
      },
      "linkTypes": {
        "DocumentDistributedAt": "lt_01HF...",
        "ActionItemFromMeeting": "lt_01HF..."
      }
    }
  },
  "processTemplate": {
    "processTemplateId": "pt_01HF..."
  }
}

If you see 413 the archive exceeded the 10 MB compressed cap. The shipped bundle is ≈ 4 KiB, so a 413 means the file was modified — re-download.

If you see 409 system_template_conflict the slug ai-boardroom is already owned by the auto-installed system template. Fork to a custom slug (see the "Customising the bundle" section) — or use the system template directly without uploading anything.

Step 4 — Create a new meeting instance

Open your Scrydon deployment at $SCRYDON_URL/process-flows. The AI Boardroom (Helios Renewables Q1) card should appear under the Governance tag. Click New from template and give the instance a name, e.g. Helios Q1 2026 Board Meeting.

The instance opens on the kanban view by default (set by defaultView in the template). You should see three stage columns:

• Preparation (14 tasks)
• Meeting (4 tasks)
• Post-processing (7 tasks)

The first task — Create meeting agenda — is unblocked and assigned to the executive persona. Every other task is gated by dependsOnTaskSlugs and shows as locked.

Each task that touches a board-pack document now carries an ontologyContract that names the tenant class IDs from Step 3 — so when you later query "what process-flow tasks operate on BoardDocument instances?" the ontology graph has a typed answer.

Step 5 — Set the agenda

Open Create meeting agenda and use the demo agenda as the source-of-truth.

Download 01-agenda.md — fictional 18 March 2026 Q1 board agenda with ten items, three resolutions, and a pre-read deadline.

Paste the agenda into the task's document editor (the document action), confirm the meeting date and attendee roster, then mark the task complete. The runtime materialises a BoardMeeting Object instance bound to this task (the action's ontologyContract.writes declared objectType: "BoardMeeting"). This unblocks the next task in the DAG: Upload board documents.

Step 6 — Upload the board pack

Open Upload board documents (assigned to the secretary persona). The task carries a single file_upload action that accepts the meeting's board-pack. Each uploaded file produces a BoardDocument Object instance linked to the meeting via the DocumentDistributedAt Link Type.

Download the eight realistic Helios Renewables board documents below and drop them into the upload zone. They are intentionally cross-referenced — the financials reference the CFO paper, the strategic plan references the acquisition proposal, the risk register references the supply-chain situation — so the AI agents have a coherent context to reason about.

To grab all eight in one go:

mkdir -p helios-q1-2026 && cd helios-q1-2026
for f in 01-agenda 02-ceo-letter 03-cfo-q1-financials 04-strategic-plan-update \
         05-acquisition-proposal 06-risk-register-update \
         07-compliance-audit-report 08-resolution-pack; do
  curl -O https://docs.scrydon.com/static/ai-boardroom/$f.md
done

Drop all eight into the upload zone, mark the task complete, and the AI pipeline starts.

Step 7 — Watch the AI pipeline

Six tasks in the Preparation stage now execute automatically (they have executionMode: "automatic" and an @system/agent-* workflow). You'll see them flip from grey → blue → green in the kanban view as they complete. Order is governed by the DAG:

Upload documents
    └── AI: Classify documents
            └── AI: Generate SMART preread
                    └── (Executive) Review and edit preread
                            ├── AI: Financial analyst        ┐
                            ├── AI: Legal advisor            │
                            ├── AI: Risk assessor            │ (six agents
                            ├── AI: Strategic advisor        │  run in parallel
                            ├── AI: Compliance officer       │  once preread
                            └── AI: Operational analyst      ┘  is approved)
                                    └── (Executive) Review agent analyses
                                            └── AI: Consolidated summary
                                                    └── (Secretary) Finalize preparation

Once all six agents complete and the executive marks Review agent analyses done, the Consolidated summary agent produces a single executive briefing that names the three resolutions, summarises the analyst consensus, and lists the items where two or more agents disagreed (in this pack the financial and strategic agents disagree on whether to bifurcate the pivot vs. M&A decisions — that gets surfaced for board discussion).

Step 8 — Finalize preparation

The Finalize preparation task is a manual checklist action assigned to the secretary. It's the gate between the Preparation stage and the Meeting stage. The default checklist asks you to confirm: (1) all materials uploaded, (2) preread approved, (3) analyses reviewed, (4) consolidated summary distributed to board members, (5) attendees and quorum confirmed.

Mark the checklist complete. The instance auto-transitions into the Meeting stage.

Step 9 — Record the meeting

The Meeting stage opens with Record meeting — a voice_trigger action scoped to the board-meeting path. In production you would open the meeting recorder app, capture live audio, and submit it. For the tutorial you can use the supplied sample transcript.

Download a sample meeting transcript (fictional 90-minute meeting where the board approves all three resolutions; the Solarcraft vote passes 6–0 with Director Almeida recused).

Upload the transcript (.txt or .vtt accepted), mark the task complete, and the two parallel agents kick in: AI: Analyze transcript and AI: Generate compliance alerts.

The compliance-alert agent inspects the transcript for:

• Conflicts of interest (does Director Almeida actually recuse on the record? — yes, in the sample transcript)
• Quorum at the time of each vote (Yes — 7 of 8 present, ≥ 5 required)
• Named-vote handling for Resolution R-2026-Q1-03 (Yes — Chair calls each director by name)
• Undisclosed related-party transactions (None detected)
• Fiduciary-duty concerns (None detected)

Review the alerts in Review compliance alerts. Acknowledge each one (the sample transcript produces three green alerts and zero red); the stage advances.

Step 10 — Post-processing

Three agents now run in parallel:

• AI: Generate meeting minutes — produces formal minutes covering attendance, agenda items, key arguments, voting outcomes, and resolutions adopted.
• AI: Extract decisions — pulls every formal decision into structured rows: decision text, vote breakdown, dissenting opinions, attached conditions. For Helios Q1 you'll see all three resolutions plus the capex-reallocation endorsement.
• AI: Extract action items — assignees, deadlines, dependencies. Six action items get extracted from the sample transcript, including "CFO + CEO: sign Solarcraft SPA on or before 5 May 2026 within €175–195 m EV band" with owner, deadline, and a link back to Resolution R-2026-Q1-03. Each extracted action item materialises as an ActionItem Object instance linked to the BoardMeeting via the ActionItemFromMeeting Link Type.

Open Review meeting minutes and edit any field; the document is then Approved by the executive (the approval action), and Finalize post-processing archives the instance.

Step 11 — Two-week follow-up

The template ships with one timed-unlock task: Post-meeting action item review (2 weeks). This task uses unlockAfterTaskSlug: "finalize-post-processing" with unlockDelay: { value: 2, unit: "weeks" }. It appears in the secretary's queue exactly two weeks after the instance is closed, asking you to revisit action-item progress and escalate stalled items.

For the tutorial you can fast-forward the timer in the dev tools: open the instance, run

curl -X POST "$SCRYDON_URL/api/process-instances/$INSTANCE_ID/dev/fast-forward" \
  -H "Cookie: $SESSION_COOKIE" \
  -d '{"by": "P14D"}'

and the follow-up task unlocks immediately.

Three error variants worth seeing

Customising the bundle

Most teams want to tweak personas, swap in their own workflow IDs for the six specialist agents, add a custom compliance-pack post-processing step, or extend the ontology with their own Object Types (e.g. ShareholderResolution, RegulatoryFiling). Three options, in increasing order of permanence:

1. Fork the manifest in TypeScript. Copy packages/sdk-authoring/src/process-flows/templates/ai-boardroom/index.ts into your own SDK project, change package.id and template.slug to a custom value, bump package.version, and bunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist. Re-upload via the same import endpoint. To extend the ontology, mirror the structure under packages/sdk-authoring/src/packs/examples/ai-boardroom/ontology/ and register your own ontology subdir.
2. Edit process-flow/manifest.json or ontology/manifest.json inside the archive. Extract → edit → re-pack with tar -czf. Quick for one-off changes (e.g. renaming the secretary persona to "clerk"); not recommended for ongoing maintenance.
3. Use the system template directly. If you don't need a customised slug or extra ontology types, drop the pack and use the auto-installed ai-boardroom system template — no upload required.

If you fork, always change the slug and package.id away from ai-boardroom so your customised template doesn't collide with the auto-installed system template or future tutorial updates.

Where to go next