Platform overview

One platform from first draft to audited production.

KrewOS covers the whole lifecycle — assemble from verified components, test against evaluation suites, release immutably, run durably, and improve from the corrections your experts make anyway.

Four levels, one vocabulary.

The same four words are used in marketing, in the documentation, in the product and in the manifest schema. Vocabulary drift is how governance quietly stops meaning anything.

LevelDefinitionDeclaresReused as
AgentA single role with a typed input and output contract, a model profile and a permitted tool set.Inputs, outputs, tools, knowledge, cost bandA block in any Pod
PodA cooperating group of Agents with an internal coordination pattern — sequential, parallel, panel or router.Composed contract, internal topologyA collapsible node in any Crew
Crew TemplateA complete, runnable workflow for a business outcome, including human control points and declared effects.Outcome unit, evidence floor, approval gatesThe starting point for a project
KrewOS PackA licensed vertical bundle of Crew Templates, Knowledge Packs, deterministic policies, evaluation datasets and dashboards.Jurisdictions, currency date, update cadenceAn entitlement on your tenant

The manifest is the source of truth.

The canvas is an editor, not the source of truth. Visual edits, plain-English changes and Git commits all resolve into one versioned Crew Manifest that can be validated, diffed, exported, tested and deployed. This is what stops your AI system becoming a design file nobody can review.

One artefact, three editors

Studio canvas, plain-English change plans and a Git repository are three views of the same manifest. None of them is privileged.

Diffable and reviewable

Every change produces a structured diff a reviewer can read, plus a validation result and a test run, before anything is applied.

# crew-manifest.yaml (extract)
apiVersion: krewos/v1
kind: CrewTemplate
metadata:
  name: lawcrew-document-review
  version: 4.2.0
  pack: [email protected]
outcome:
  unit: matter_reviewed
  baseline_minutes: 52
evidence:
  floor: 0.72
  on_insufficient: abstain_and_report
control:
  human_review: full   # regulated floor
  approver_role: qualified_professional
effects:
  reads: [matter_store, sg_statutes]
  writes: [draft_artefact]
  external: []          # no side effects declared

Three surfaces.

Build in Studio, reuse through the Hub, operate in the Runtime. Governance is common to all three rather than bolted onto one of them.

Studio

Template-first assembly, typed ports that refuse invalid connections, plain-English change plans with diffs, and guardrails that fire before you can test. Explore Studio →

Hub

A verified catalogue, not an open marketplace. Five verification tiers, fourteen classification dimensions and private tenant catalogues. Explore the Hub →

Runtime

Durable runs, human wait states, idempotent actions, binding budgets, immutable releases and complete traces. Explore the Runtime →

Control Plane and Execution Plane.

Governance stays central; execution can move. That is how you get one governance model across the organisation and still satisfy a residency requirement that differs by entity.

Control Plane

Central

Identity & RBAC Hub catalogue Manifests Policies Evaluation suites Releases Audit index Billing & credits

Execution Plane

Placeable

Compiled run plan Run state Knowledge indexes Model gateway calls Tool and Action execution Working artefacts

Compare the five deployment models →

What we deliberately do not do.

Published on purpose. A shorter list of honest limits builds more trust with a risk committee than a longer list of features.

  1. We are not an unrestricted marketplace

    Every published component is reviewed and verified against a stated bar. Anyone can publish into their own tenant catalogue; nobody publishes to the world unreviewed.

  2. We do not build self-modifying production crews

    Plain-English changes produce a change plan for a human to accept. A running release never rewrites itself.

  3. We do not replace n8n, your ERP, CRM or data warehouse

    We call them, under a permission and audit boundary. Rebuilding four hundred connectors is not our product.

  4. We do not train foundation models

    We govern access to approved ones. No customer data is used to train models, ours or a provider’s.