Using in workflows

Workflows use the ontology through four tools, all exposed by the scrydon:ontology product. They show up in the Tools picker of any Agent block.

The four tools

Each tool is typed — the LLM sees the object types and link types your organisation has defined, and it can call them by name.

How the tools run

These tools do not run inside the workflow sandbox. Scrydon executes them in process, on your behalf, after it has authorised the call, taken any confirmation the operation requires, resolved the object references the block declares, and run the DLP scan. Each call then reaches the ontology carrying your identity — your user session, or the execution grant a scheduled run acts under — never a service identity.

That is what makes the guarantees at the bottom of this page enforceable rather than aspirational: the ontology authorises a principal, so masking, row filters and action grants are resolved against you, not against the workflow engine. A run that cannot present an exact verified identity does not fall back to a broader one — the tool fails with principal_required and the workflow sees the error.

Get Ontology Object

Input:
  objectType: "RegulatedEntity"
  objectId:   "e1a2b3c4-0001"
Output:
  id:         "e1a2b3c4-0001"
  classId:    "RegulatedEntity"   // v2 identifies an Object Type by its api name
  className:  "RegulatedEntity"
  properties: { legalName, riskClassification, headquartersCountry, … }

Both objectType and objectId are required: an Object is addressed by its Object Type and id, never by id alone. Properties the caller doesn't have clearance to see are masked according to the column's mask strategy (redact, null, deny) before they leave the ontology, so a masked value arrives masked.

Traverse Ontology Links

Input:
  objectType: "RegulatedEntity"   // the Object Type of the starting instance — required
  objectId:   "e1a2b3c4-0001"
  linkType?:  "supervisedBy"      // omit to follow every Link Type
  depth?:     1                   // 1–3, default 1
Output:
  nodes: [ { objectType, objectId, properties, … } ]
  edges: [ { linkId, linkType, sourceRef, targetRef, direction, … } ]

objectType is required for the same reason it is on Get Ontology Object: the neighbours read is keyed by (Object Type, id). In the Ontology block the Object Type picker is shown for both Get Ontology Object and Traverse Links; an Agent block supplies it as a tool argument. nodes and edges are index-aligned — edges[i] is the Link that connects the starting instance to nodes[i] — and the starting instance itself is not in nodes. Each neighbour is a fully typed Object (same projection as Get Object). Masking and row filters apply.

Run Ontology Action

Input:
  actionType:  "AssignAsset"
  subjectRef?: "asset-0001"       // id of the subject Object instance
  input?:      { assetId, userId }
Output:
  outboxId:    "act_01J…"          // the committed action's id
  status:      "committed"
  idempotent:  false               // true when a retried run replayed an earlier commit

Action dispatch passes through the policy decision point. A retry of the same workflow run replays the earlier commit rather than dispatching twice (idempotent: true). Failures come back as typed errors the agent can branch on.

Search Ontology

Input:
  query:    "regulators supervising Acme Holdings"
  ontology?: "compliance"   // omit to search every readable ontology
  limit?:   20
Output:
  results:  [ { objectType, id, properties, matchedVia } ]
  counts:   { ontology, lexical, merged }
  poolSize: 412
  poolCapped: false

Each result says how it was found (matchedVia): from the structured query the LLM derived, from the keyword search, or both. poolSize is the number of governed rows the search evaluated; when poolCapped is true the evaluated window hit the server cap, so the counts are approximate rather than exhaustive. Masking and row filters apply to every result.

The Agent block

In an Agent block, attaching the scrydon:ontology tools gives the agent access to all four. The LLM sees the object types and link types as part of the tool schema; it can plan calls like "find the regulator that supervises Acme Holdings" without hardcoded table names.

Selecting an object instance

When a workflow field asks for an object instance, the editor uses two steps:

1. Select a bound object type. Only types connected to an active data source are available.
2. Select an object of that type from the bounded result list.

The editor saves a stable reference with exactly the object type and object ID, for example { objectType: "RegulatedEntity", objectId: "e1a2b3c4-0001" }. The displayed label is only presentation data and is not saved as the reference.

After a reload, the editor displays the first available non-empty value from the object's name, displayName, or label property. If none is available—or the object is outside the first result page—it displays the object ID. This fallback does not change the saved reference.

Common patterns

Retrieval-grounded answer

User: "What's the risk classification of Neptune Capital?"
Agent → Get Ontology Object(type=RegulatedEntity, lookup=Neptune Capital)
Agent → returns risk classification + provenance citation

Multi-hop traversal

User: "Which regulators supervise high-risk entities in Belgium?"
Agent → Search RegulatedEntity (filter: country=Belgium, risk=high)
Agent → For each: Traverse "supervisedBy" link
Agent → Aggregate distinct regulators

Action with guardrails

User: "Assign asset A-123 to Maya"
Agent → Run Ontology Action(AssignAsset, { assetId: A-123, userId: Maya })
Action → PreconditionFailed: asset-unassigned (asset is currently assigned to John)
Agent → reports the failure, asks the user to confirm reassignment

What the agent doesn't see

• Raw column names. The agent operates on typed properties (riskClassification), not on risk_class columns.
• Other tenants' data. Authorisation is enforced at every tool call.
• Masked values. Properties the calling user can't see come back masked.
• Actions the calling user can't dispatch. The tool schema is filtered to the actions the caller has grants for.

Related

• Object types — what the agent reads.
• Link types — what traversal walks.
• Action types — what dispatch executes.
• Blocks → Agent — where the tools are attached.