Knowledge & Capabilities

Knowledge & Capabilities define what a workflow can safely use. Knowledge contains approved source material. Capabilities are approved actions, integrations, and tools that can fetch live data, save a record, call an approved service, or operate a connected website.

The workflow owns inputs, outputs, and handoffs. The persona decides how to speak and when to ask for confirmation. Knowledge & Capabilities define the safe boundary.

Start with the workflow boundary

Before adding a capability, decide:

• What the workflow is allowed to do.
• Whether it is read-only or writes data.
• Which fields the workflow can send.
• What confirmation is needed before a change.
• What error message should be shown to a user.

The capability definition should be narrower than the underlying system. If the workflow only needs to create leads, expose a create-lead function instead of a general database endpoint.

Common capability patterns

Pattern	Example	First-pass safety rule
Lookup	Check appointment slots or order status.	Read-only and scoped to one record type.
Capture	Save lead details from a chat.	Require the user to provide contact details first.
Draft	Create unpublished content.	Do not publish automatically.
Update	Change a website content field.	Confirm record and field before writing.
Website action	List, create, update, or delete approved resources.	Use website resource permissions and confirm destructive changes.

Link capabilities to a workflow

Functions and integrations are reusable. Create the capability once, then link it only to workflows that need it. Test the workflow with a prompt that clearly requires the capability and a prompt that should not.

Write clear tool descriptions

The model chooses capabilities from names, descriptions, and parameters. Use plain descriptions:

{
  "name": "create_lead",
  "description": "Save a new sales lead after the visitor provides name, contact method, and interest.",
  "parameters": {
    "name": "string",
    "contact": "string",
    "interest": "string"
  }
}

Avoid generic names like call_api or run_action. They make capability choice less predictable.

Handle tool failures

Tell the persona how to recover:

• If a required field is missing, ask a follow-up question.
• If a resource is unavailable, explain what failed in user language.
• If a write action is denied, do not retry with broader permissions.
• If a destructive action is requested, ask for explicit confirmation.

Website capabilities

When a workflow is connected to a website, the connection exposes only selected resources and actions. The workflow can list resources, inspect available fields, and operate allowed records through that connection. If a resource is not available, update the website permissions rather than weakening the persona.