Solution Packs

What it is

Solution Packs are pre-built, domain-specific collections of agents, prompts, workflows, and squads for a vertical (Insurance, Financial Services, HR, Customer Support…). They solve the "blank page" problem — start from production-tested components instead of building from scratch. Packs are pure configuration (JSON), decoupled from the core platform, installed via API.

When to use it

Use a pack to stand up a working demo or PoC in days, or as a reference architecture for a domain. Install the pack, connect your data sources, then customise any component. The platform is the same across domains — only the integration layer and data source change.

• Use a pack as-is when the shipped agents/workflows match your process and you only need to swap config (model, temperature) or point integrations at your systems.
• Fork a component when you need to change content — a prompt's extraction schema, a workflow's node graph, or a squad's composition. Forking (planned) keeps your edits safe from pack updates via copy-on-write; today you achieve the same by cloning the component manually.
• Build a custom pack when no shipped pack fits — use an existing pack as the worked example.

How it works

Process flow — install to live:

Call flow — installation:

Sub-features

• Three tiers + prompts — agents, workflows, squads (each builds on the one below), plus the domain prompts that give agents their expertise.
• Idempotent install — re-installing upserts by slug; unmodified system components are updated in place, forked copies are skipped.
• Copy-on-write customisation (planned) — system components are read-only; "Customize" forks a user-owned copy with forked_from, never overwritten by updates. The read/uninstall paths already honour forked_from; the fork-creation action is coming soon.
• Demo self-sufficiency (planned) — packs are intended to ship sample data + mock integrations for standalone demos. Mock-integration bundling is roadmap.

Configuration parameters

Pack manifest (manifest JSON)

The bundle is { manifest, prompts[], agents[], workflows[], squads[] }. The manifest carries pack identity; the four arrays carry the components.

Per-component definitions (in the bundle arrays)

The installer maps each array element onto the matching content type. Unlisted fields fall back to sensible defaults.

Every seeded component is tagged pack_slug, pack_version, and linked to the solution_pack registry entry; agents/squads/packs also record an owner.

Install-time env

Dependencies

• Core platform — workflow engine, agent runtime, squad executor, prompt service (all packs share these). See Agents, Squads, and the Visual Workflow Builder.
• solution-pack registry + installer API in DMS (built).
• Integrations — packs reference your email, document storage, CRM, etc. See Integrations.
• Pack seed files — today packs live in dms/src/seeds/packs/. A separate turfai-packs distribution repo with build-bundle.js tooling is coming soon.

Limitations

• Pack quality depends on its prompts and sample data; domain SME tuning is expected.
• No update / export / import endpoints yet — POST /update, POST /export, POST /import from the model doc are not implemented. Re-running install is the only "update" path.
• No UI fork action yet — the schema and install/uninstall logic respect forked_from, but no endpoint creates a fork. Customise by cloning a component manually until this ships.
• No marketplace / GCS distribution — packs are local seeds, not a remote registry.

Concrete examples

Pack manifest excerpt

{
  "manifest": {
    "name": "Insurance Pack",
    "slug": "insurance",
    "version": "2.0.0",
    "category": "industry",
    "icon": "🛡",
    "color": "#2563eb",
    "description": "Claims, underwriting, compliance & broker support"
  },
  "prompts":   [ /* 14 domain prompts */ ],
  "agents":    [ /* 14 single-purpose agents */ ],
  "workflows": [ /* 7 end-to-end automations */ ],
  "squads":    [ /* 3 multi-agent teams */ ]
}

Reference example — the Insurance pack composition

This is the shipped reference pack (dms/src/seeds/packs/insurance.json, v2.0.0):

A squad in the bundle declares its agents inline with a per-step role and task — e.g. the Claims Settlement Squad runs five agents sequentially:

{
  "slug": "insurance-claims-settlement-squad",
  "name": "Claims Settlement Squad",
  "process": "sequential",
  "agents": [
    { "slug": "insurance-evidence-collector",  "role": "Evidence Coordinator", "task": "Determine required evidence; flag blocking items." },
    { "slug": "insurance-coverage-analyst",    "role": "Coverage Analyst",     "task": "Decide whether the event is covered; list exclusions." },
    { "slug": "insurance-claims-valuator",     "role": "Claims Valuator",      "task": "Calculate the fair settlement amount." },
    { "slug": "insurance-settlement-drafter",  "role": "Settlement Drafter",   "task": "Draft the settlement offer letter." },
    { "slug": "insurance-compliance-reviewer", "role": "Compliance Reviewer",  "task": "Check the offer for regulatory compliance." }
  ]
}

Beyond Insurance, six more packs ship today: financial-services, hr-recruitment, customer-support, education-learning, operations-it, project-management.

Fork example (planned shape)

When the fork action ships, customising a component will create a user-owned copy that points back at the original and is never touched by pack updates:

// System component (read-only)
{ "slug": "insurance-fnol-intake", "is_system": true,
  "pack_slug": "insurance", "pack_version": "2.0.0" }

// "Customize" -> user-owned fork (fully editable)
{ "slug": "insurance-fnol-intake-custom", "is_system": false,
  "forked_from": "insurance-fnol-intake", "owner": "<user.id>" }

Today you reproduce this manually: clone the component, edit the copy, and point your workflow/agent at the clone. Uninstall already preserves anything with a forked_from value.

Tips & best practices

• Install → configure → fork → deploy. Install the pack, point its integrations at your systems and adjust config-only fields (model, temperature, max_iterations) in place; fork only when you need to change prompt content or graph structure; then run the workflows/squads.
• Fork vs use-as-is. Use as-is for config tweaks (those are safe to edit on the system component). Fork for content changes — editing a system prompt or workflow graph in place will be overwritten when the pack updates (once updates ship), so fork to protect it.
• LLM-agnostic. Packs set model: vertex by default but the field is per-agent and free to change — agents run on Gemini/Vertex, OpenAI, Claude, or a self-hosted model. Packs are JSON, so nothing is locked to one provider.
• On-prem / data residency. Packs deploy wherever TurfAI runs; no data leaves your infrastructure. Set a pack-level data_shield_policy in the manifest to ship a default tokenisation posture that the pack's workflow activities inherit — see Data Shield.
• Idempotency is your friend. Re-running install is safe: unmodified system components are upserted, forks are skipped. Use it to refresh a pack after editing the seed file.

Troubleshooting

How to test

1. List available packs — GET /api/solution-packs/available returns every seed pack with its component_count and installed flag.
2. Install — POST /api/solution-packs/install-by-slug/insurance (or POST a full bundle to /api/solution-packs/install). Check the response summary shows components created.
3. Verify components created — GET /api/solution-packs/:id returns the registry entry with populated agents / workflows / squads / prompts; or filter the component lists by pack_slug=insurance. Each should be tagged is_system with pack_version: 2.0.0.
4. Run it — execute insurance-claims-intake or the Claims Settlement squad against a sample input and confirm the expected output.
5. Fork a component (coming soon) — once the fork action ships, "Customize" an agent, confirm a forked_from copy is created, then re-install and confirm the fork survives (uninstall preserves forks today).
6. Uninstall — DELETE /api/solution-packs/:id/uninstall removes system components in reverse order and leaves any forked_from copies in place.

Cross-links & roadmap

Related pages

• Agents — the single-purpose workers a pack ships.
• Squads — the multi-agent teams; pack squads declare agents inline with roles/tasks.
• Visual Workflow Builder — where pack workflows render and run.
• Prompt Lab — the domain prompts that give pack agents their expertise.
• Integrations — connect pack workflows to your email, storage, and CRM.
• Data Shield — set a pack-default data_shield_policy.

Coming soon (forward-looking)

APIs used

See the synced solution-packs reference.