Foundation's AI support is based around the concept of an "intelligence engine", which provides "intelligence services".
An intelligence engine is represented by a node, and that node would typically invoke a large language model (LLM) to provide the service.
Intelligence service interfaces are standardised within Foundation. Intelligence engines are conventionally available using the binding "intelligence", allowing solutions to access intelligence services without knowing the detail of the engine. However, solutions may access intelligence services in different ways.
Intelligence engines are executed using the canonical call model supported by Request manager. In this, the parameters to the call are passed in a single JSON object in the <body> element, and the responses returned in a JSON object in the <return> element. The call parameters and response data are in a "data" property within these JSON objects.
An intelligence engine uses the standard "action" property (read from the <action> element or the request parameters) to identify an action. The actions are described below.
| Action | Description | Request data | Response data |
| listServices | Returns a list of supported services. |
none |
services - an object with a nested object for each supported service, e.g. {
|
| textGenerate | Perform a simple, synchronous text-based generation. |
request - the prompt or input request options - additional options. |
response - the generated response info - an object containing optional information about the call. Format is not defined, may be used for logging. |
| generate | Perform a simple, synchronous text-and file-based generation. |
As for textGenerate, plus: requestAttachments - array of node references or file info objects for attachments to the request |
As for textGenerate, plus: responseAttachments - array of node reference or file info objects for attachments to the response |
List services
Engines that are intended for general use should support listServices to indicate what services they support, and callers to general services should check that the required service is available using listServices. This returns in "services" an object of objects. (This format allows additional properties to be added if required, though this is not currently used.)
Options
Options allow the caller to specify how they want the engine to act. However, to preserve interchangeability of options, the following rules apply:
- The engine should provide defaults for all options, and options is optional.
- The engine should not raise an error if there are options that it does not recognise.
Call conventions
Engines may support passing <data> in place of <block> and using <action> in place of the "action" property, for compatibility with earlier conventions. This is handled transparently by the request manager; engines should indicate if this is permitted.
File handling
Callers and engines should use File Info Script to resolve the files passed into the engine and returned from the engine, to allow the caller or the engine to pass files either as nodes or as file info objects.
Example
A simple call (in XML form) might be
<ExecuteScript>
<nodeVersionReference>engine.reference</nodeVersionReference>
<body>{
"action": "textGenerate",
"data": {
"request": "Tell me about guppies"
}
}</body>
</ExecuteScript>
And a response
<ExecuteScript>
<errorNumber>0</errorNumber>
<return>{
"status": "success",
"data": {
"response": "Guppies (*Poecilia reticulata*) are small, colorful freshwater fish..."
}
}</return>
</ExecuteScript>