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…). With a pack you start from production-tested components instead of a blank page. Packs are pure configuration (JSON), decoupled from the core platform, and you install them through the API.

The TurfAI website calls these Domain Packs.

When to use it

Use a pack to stand up a working demo or PoC, or as a reference architecture for a domain. Install the pack, connect your data sources, then customise any component. The platform stays 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. Fields not listed here fall back to 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. The copy points back at the original, and pack updates never touch it:

// 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 — call GET /api/solution-packs/available. It returns every seed pack with its component_count and installed flag.
2. Install — call POST /api/solution-packs/install-by-slug/insurance (or POST a full bundle to /api/solution-packs/install). Check that 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.