Autologyx Docs

Appearance

Knowledgebase terminology index ​

This file is built from the saved terminology store.

actor ​

In the Autologyx platform, an actor is a configurable step in a Sequence that performs a specific action within a workflow, such as calling an API, setting a local variable, or invoking a dedicated AI capability like the OpenAI: GPT actor. Actors are added in the Sequencer by dragging them onto the Sequence canvas and then completing their settings in the actor configuration modal, where the behaviour of that step is defined. Dedicated actors are provided for common integrations and use cases, while generic patterns such as the API Call actor are used when a workflow needs to interact with external services that do not have a dedicated provider actor. Actors matter because they are the building blocks of Sequence design: they determine how data is processed, how systems are connected, and how each automated action is executed in a controlled workflow.

actor configuration modal ​

The actor configuration modal is the setup dialog in Autologyx used to configure an actor’s runtime settings before it is used in a workflow or integration. In the context of the OpenAI ChatGPT actor, this modal is where configuration admins and developers define the model, authentication, prompt, context, temperature, and test record, so the actor can be connected to the correct service and behave as intended when processing data. It is used when creating or updating AI-enabled actors and works alongside related platform concepts such as Authentication Objects, merge fields, Object Records, and Record IDs to supply credentials, dynamic inputs, and test data. This matters because the values entered in the modal directly control how the actor executes, what data it uses, and how reliably it can be validated before deployment.

agentic workflows ​

Agentic workflows are workflow patterns in Autologyx where an AI assistant or autonomous agent works toward a defined goal by selecting from approved tools and executing process steps within configured boundaries. They are used in the Applied AI capabilities of the platform and are typically implemented alongside workflow components such as agents, Loop actors, API Call actors, and human-in-the-loop controls to coordinate automation with operational oversight. Agentic workflows matter because they enable more adaptive, outcome-driven automation than fixed step-by-step orchestration while still requiring platform governance, permissions, auditability, and clear ownership so configuration teams, integrators, and compliance stakeholders can deploy AI-enabled processes safely and consistently.

AI and the Sequencer ​

AI and the Sequencer is the Autologyx capability for incorporating AI services into Sequencer-driven workflows, allowing Sequence steps to call configured AI models while remaining part of the platform’s orchestration and deterministic Sequence logic. It is used when configuration admins, developers, and super admins set up providers, models, and actors such as the Bedrock actor so Sequences can use services delivered through platforms like AWS Bedrock. This matters because it defines how AI is connected to and governed within Autologyx: AI is not configured as a standalone workflow outside the Sequencer, but as an integrated execution option within Sequences, using approved provider and model combinations that align with the customer’s platform and cloud configuration.

API Call actor ​

The API Call actor is a Sequencer actor in the Autologyx platform that sends outbound REST requests from a Sequence to external services, including AI endpoints, customer-controlled gateways, and privately hosted models where no native actor is available. It is configured within a Sequence to pass record data, extracted document text, prompts, instructions, and other structured inputs to an API, then receive JSON responses that can be stored on the source record or passed to later actors for further processing. This actor matters to configuration admins and developers because it provides a flexible integration pattern for connecting Catalyst workflows to supported and non-native AI services, private model infrastructure, and reusable automation designs without requiring a dedicated product-specific actor.

API method ​

In the Autologyx platform, an API method is the authentication method selected on an Authentication Object when a service connects to an external system by using that system’s API credentials rather than an interactive user sign-in flow. It is used during configuration by administrators and integrators setting up actors and service integrations, such as the OpenAI: GPT actor, where the Authentication Object must be configured with the API method to store and use the required API key. This matters because the chosen method determines how Autologyx authenticates outbound requests, enabling the platform to securely access external services and allowing integrations to run correctly within workflows and AI-driven automation.

Applied AI ​

AppliedAI ​

AppliedAI in Autologyx is the platform capability that embeds AI services into structured, governed Catalyst workflows, allowing organisations to understand, summarise, extract, and act on unstructured information within a controlled process rather than through a standalone tool. It is used in workflow design and execution, especially with the Sequencer, where defined workflow steps send structured requests to AI services, receive responses, and use those outputs in later steps as part of an agentic workflow orchestrated by Autologyx. AppliedAI is model agnostic and works alongside related platform components such as API Call actors and MCP services, while operating within Autologyx security, permissions, auditability, and hard-stop access controls. This matters to configuration admins, developers, integrators, and end-users because it enables AI-assisted automation at scale without giving up process control, policy alignment, transparency, or the predictable operation of business workflows.

AppliedAI and the Sequencer ​

AppliedAI and the Sequencer, also described as the Sequencer pattern, is the AppliedAI design pattern in Autologyx where Catalyst workflow automation initiates outbound requests to AI services, orchestrates each step of the interaction, and uses returned outputs within a controlled workflow. It is used in Catalyst processes that send structured prompts and record context to supported AI endpoints, including native integrations and API Call actor connections to external or privately hosted models, and it can be combined with Loop actors and reusable playbook-style Object Classes for repeated extraction, classification, or content-processing tasks. This pattern matters because it keeps AI activity inside human-designed, auditable business processes, allowing configuration admins and developers to control when AI is called, how responses are consumed in later steps, which services and models are used, and how governance, transparency, and access control are enforced across AI-driven workflow automation.

approved agent ​

An approved agent is an AI assistant or agent that has been explicitly enabled within Autologyx to use MCP Work tools under the customer’s configured permissions, enabled capabilities, and governance controls. In the Autologyx platform, approved agents are used in MCP Work to participate directly in operational processes by working alongside users or within controlled autonomous workflows, including activities such as finding and reading records, updating structured data, creating related records, managing tasks, and generating documents where permitted. This matters because approval determines which AI assistants and agents are allowed to operate in the system of record, ensuring that operational actions are limited to authorised tools and configurations for end users, administrators, and compliance teams.

asynchronous Object Record hierarchy creation process ​

The asynchronous Object Record hierarchy creation process is an Autologyx background operation that creates an Object Record together with its related child Object Records as a hierarchy without requiring the caller to wait for completion in the same request. It is used by developers and integrators through MCP Work tooling, where one tool starts the hierarchy creation and the companion check object records hierarchy creation tool is used to retrieve the process status after submission. This matters when integrating with Autologyx because creating parent and child Object Records as a single asynchronous process supports structured data onboarding at scale, allows long-running hierarchy creation to be monitored separately from the initial request, and helps external systems coordinate follow-up actions only after the hierarchy has finished processing.

Auth Object ​

An Auth Object, or Authentication Object, is the Autologyx configuration item used to supply the credentials and authentication method required when the platform connects to an external service. In the AWS Bedrock integration, the Auth Object is selected in the integration configuration to authenticate requests sent to AWS Bedrock, and it must be set up to use the customer’s approved AWS authentication approach. This matters to configuration admins and developers because the correct Auth Object is essential for establishing secure connectivity, enabling the integration to function, and ensuring the platform uses the intended access model when invoking external services.

Authentication Object ​

An Authentication Object is an Autologyx configuration item that stores the credentials and authentication settings used by the platform to connect securely to external services and APIs. It is selected in actor and integration configuration wherever an Auth Object field is shown, including OpenAI, Azure OpenAI, AWS Bedrock, privately hosted model connections, and related Test Integration or System Configuration Sequence setup steps. Authentication Objects matter because they provide a reusable, centrally managed way to supply approved API keys or cloud authentication details, helping administrators, super admins, and integrators standardise external connections, simplify configuration, and keep authentication separate from individual workflow or actor definitions.

Autologyx Catalyst ​

Autologyx Catalyst is the core Autologyx platform environment that orchestrates workflow-driven processing, including AI-augmented automation through Sequencer-based workflows. In Catalyst, configuration admins, developers, and super admins use the Administration area, Sequence builder, actors, integrations, and API-based tooling to define how work is triggered, routed, processed, and audited. Within AppliedAI, Catalyst serves as the model-agnostic orchestrator: it remains responsible for the workflow, data model, permissions, routing, task creation, and audit trail while invoking AI services through native actors such as the OpenAI: GPT actor, API Call actors, and related integrations. This matters because Catalyst is the platform layer where organisations configure controlled, production-grade processes that combine business workflow automation with external AI services, hosted models, private endpoints, and reusable agentic or MCP-enabled patterns.

Autologyx Classification ​

Autologyx Classification is the platform’s content classification label shown in documentation and configuration contexts to indicate the handling category assigned to Autologyx material or capabilities. In the supplied Applied AI and MCP documentation, it is used as a page-level designation such as “Unrestricted, Public,” helping super admins, configuration admins, and compliance stakeholders identify whether information about features like Public AI Providers, Embedding Model Actors, API Call actors, and MCP services is approved for open sharing and standard use. This matters because the classification provides a clear governance signal for how platform information should be distributed, reviewed, and consumed when enabling integrations, documenting solutions, or managing security and compliance expectations.

Autologyx Classification: Unrestricted, Public ​

Autologyx Classification: Unrestricted, Public is the platform’s data-handling classification for capabilities, providers, or configurations that are approved only for information intended to be openly shareable and not subject to internal, confidential, personal, or regulated handling controls. In Autologyx documentation and configuration guidance, this classification is shown on items such as public AI provider integrations, including OpenAI-related actors and embedding actors, to indicate the permitted sensitivity of data that can be sent to or processed by that component. This classification matters to Super Admins and compliance-focused users because it determines whether a feature is appropriate for a given use case, informs provider selection and authentication design, and helps ensure that workflows, prompts, documents, and outputs are aligned with organisational information security and governance requirements.

Autologyx configuration experience ​

Autologyx configuration team ​

The Autologyx configuration team is the specialist group responsible for designing and implementing platform configuration required to deliver customer solutions in Autologyx, particularly where advanced integrations are involved. In documentation, the term is used in the context of privately hosted model integrations, where the Autologyx configuration team works jointly with the customer’s AI, data science, security, and cloud platform teams to define the integration design and agree production data flows. This matters to Configuration admins, Super Admins, and Developers or Integrators because these configurations directly affect how capabilities such as API-based model connections, authentication setup, API Call actors, Sequencer logic, and Sequences are structured and deployed within the platform.

Autologyx environment ​

An Autologyx environment is the specific platform instance in which organisation-level features, integrations, and controls are configured and made available for use. It is used by configuration administrators and Super Admins to enable capabilities such as the AWS Bedrock integration, define which external services can be accessed, and align platform behaviour with account, region, security, and governance requirements. In practice, whether components such as a Bedrock actor or AI-driven workflow pattern can be used in Sequencer depends on what has been enabled in the Autologyx environment. This matters because the environment determines the operational scope of the platform for a customer, controlling which integrations are available and ensuring workflows run within the organisation’s approved technical and compliance boundaries.

Autologyx governance gateway ​

The Autologyx governance gateway is the platform control layer used to govern how MCP-enabled agents access and use MCP services within Autologyx. It is used when configuring MCP integrations alongside Autologyx permissions, MCP mappings, user accounts, and user groups to define exactly what an agent can see and do. In practice, the governance gateway provides finer-grained control than connector-level restriction settings in the agent client, allowing administrators to enforce platform-level access rules and operational boundaries across available MCP Work tools and related services. This matters because it helps configuration, security, compliance, and integration teams ensure agent behaviour aligns with organisational policy, approved access models, and safe service exposure within the platform.

Autologyx MCP Build ​

Autologyx MCP Build is the Autologyx platform capability area for AI-assisted Catalyst configuration, enabling supported services and agents to create and manage build components such as Object Classes, forms, Task Templates, users, groups, permissions, sequences, and related configuration assets. It is used in the AppliedAI context alongside Autologyx MCP Work and Autologyx MCP Success, extending MCP services from operational understanding into configuration and platform design activities. This matters to Configuration admins, Developers and Integrators, and Super Admins because it defines how AI can participate in building and maintaining Catalyst workflow automation while aligning with platform controls, agentic workflow patterns, and governed human-in-the-loop administration.

Autologyx MCP Customer Success ​

  • Mostly relevant to: Configuration admins, Super Admins, End-users
  • Closely related concepts: Autologyx MCP Work

Autologyx MCP Customer Success is the MCP service in the Autologyx platform that provides product knowledge, configuration guidance, and solution design support for Autologyx implementations. It is used when configuration admins, Super Admins, and end-users need help understanding Autologyx concepts, selecting configuration patterns, structuring platform components, or applying implementation guidance during setup and adoption. Referenced throughout the MCP documentation as the destination for platform knowledge questions, it complements Autologyx MCP Work by focusing on how to design and configure solutions correctly, making it important for consistent platform setup, effective solution design, and faster user enablement.

Autologyx MCP endpoint ​

The Autologyx MCP endpoint, also referred to as the Autologyx MCP endpoint URL or MCP endpoint, is the connection URL that external MCP-compatible clients use to connect to Autologyx. In the Autologyx platform, it is used when configuring a custom connector or creating a new app in supported clients so the client can sign in as a user and complete authorisation through Autologyx. This endpoint is a core part of enabling access to Autologyx MCP services, tools, and related MCP-enabled capabilities, because it defines where the client connects to start the integration and establish access to available Autologyx work through MCP.

Autologyx MCP Success ​

Autologyx MCP Success is the Applied AI capability in the Autologyx platform that provides Knowledgebase access together with design, planning, and configuration guidance. It is used where approved AI assistants support users in shaping solutions, answering platform questions, and guiding configuration activity, rather than working with live tasks or operational data. For configuration admins and Super Admins, MCP Success matters because it helps translate Autologyx best practice and Customer Success guidance into practical solution design decisions, making it easier to plan implementations, configure the platform effectively, and distinguish advisory support from the execution-focused role of Autologyx MCP Work.

Autologyx MCP Work ​

Autologyx MCP Work, also called MCP Work, is the Autologyx MCP service and tool collection used by approved AI assistants, co-pilots, and autonomous agents to perform operational work against live Autologyx data and services. It is used in Applied AI and MCP-enabled workflows wherever agents need to interact with object records, tasks, documents, sequences, and processes, including reading and updating records, assigning and completing manual or automatic tasks, and generating documents through controlled access such as approved tools and service accounts. MCP Work matters because it extends live process execution inside Autologyx, allowing users and administrators to design agent patterns, permissions, audit controls, and safe write actions so agents can work alongside end-users or operate autonomously without being used for product configuration.

Automatic Task ​

An Automatic Task in Autologyx is a task instance created from a Task Template and an Object Record, including through Autologyx MCP Work tools used by developers, integrators, and configuration administrators. It is used when the platform or an approved agent needs to create work directly against a specific record, including within parent and child Object Record structures, without relying on a user to manually create the task. Automatic Tasks matter because they let configured processes and integrations generate the right work item in the correct record context, helping ensure task creation is consistent with the selected template, aligned to the relevant business object, and available for downstream assignment, data capture, and task management in the platform.

autonomous agents ​

Autonomous agents in Autologyx are AppliedAI operating components that use approved tools to act on live Autologyx data and services within structured workflows, rather than outside platform controls. They are used in AppliedAI-enabled processes and in Sequencer-driven interactions where the platform sends structured requests to AI services, receives responses, and applies those responses in later workflow steps under defined permissions and policies. For end-users, configuration admins, and developers, autonomous agents matter because they enable AI-driven work to be executed with governance, granular access control, auditability, hard-stop gating, and clear separation between advisory behaviour and actions that change live data, allowing organisations to automate work while retaining enterprise-grade control and transparency.

autonomous pattern ​

An autonomous pattern in the Autologyx platform is an MCP usage pattern in which an agent is allowed to carry out a defined set of actions without requiring a user prompt for every step. It is used when designing and configuring Autologyx MCP Work integrations, especially when planning which available tools an agent can use, setting permissions, and applying governance controls through related platform components such as approved agents, service accounts, and the Autologyx governance gateway. This pattern matters because it changes how work is executed and controlled: autonomous patterns must be designed with narrower permissions, stronger governance, and careful risk assessment to ensure agents can act effectively within clearly defined operational boundaries.

Available MCP Work tools ​

AWS Bedrock ​

AWS Bedrock, also called Amazon Bedrock or Bedrock, is the Amazon Web Services integration used in Autologyx when a Sequence needs to call a foundation model through AWS instead of a direct public provider integration. In the platform, it is used within AI and the Sequencer through the Bedrock actor, together with related configuration such as the selected provider and model, authentication objects, and environment configurations. It matters to configuration admins and developers because it lets Autologyx workflows use models made available through Bedrock while keeping AI access aligned with the customer’s AWS account, region, governance, security, and access controls, and it supports flexible model choice across multiple providers and model families enabled in the customer’s AWS environment.

AWS Bedrock integration ​

AWS Bedrock integration is the Autologyx platform capability that enables an environment to connect to Amazon Bedrock so AI-powered features can be configured and used within Sequences and the Sequencer. It is used during platform and environment setup, where configuration admins, super admins, and developers or integrators must ensure the integration is enabled before configuring Bedrock-related components such as a Bedrock actor or testing the connection through integration setup. This integration matters because it is the prerequisite that makes Amazon Bedrock available inside an Autologyx environment, allowing teams to use Bedrock-backed AI services as part of sequence design, execution, and applied AI configuration.

Azure OpenAI actor ​

The Azure OpenAI actor is a Sequence actor in the Autologyx Sequencer that enables a workflow to call an OpenAI model through a customer’s Azure OpenAI endpoint instead of the public OpenAI API. It is used on the Sequence canvas when building AI-enabled Sequences, and is configured through the Azure OpenAI configuration modal with the required Azure connection and authentication details, typically alongside an Authentication Object. This actor matters to configuration admins and developers because it provides an enterprise-controlled route to GPT-style model access within Autologyx, aligning workflow automation with Azure-hosted networking, identity, monitoring, policy, regional, and governance requirements while allowing organisations to use approved Azure OpenAI deployments in their workflows.

Azure OpenAI configuration modal ​

The Azure OpenAI configuration modal is the settings dialog used to configure an Azure OpenAI actor in the Autologyx Sequencer. It is opened from the actor configuration on the Sequence canvas and is used by configuration admins and developers to define the Azure OpenAI endpoint, model type, model, authentication, prompt, context, temperature, and test record for the actor. This modal is important because it controls how the Sequence sends requests to Azure OpenAI, supports testing the actor against a record, and keeps credentials managed through an authentication object rather than exposing them directly in the actor configuration.

Bedrock actor ​

The Bedrock actor is the Sequencer component in Autologyx that connects a workflow to AWS Bedrock so AI model requests can be executed as part of a controlled sequence. It is used when configuring AI-enabled Sequences in the Sequencer, where administrators and integrators select a Bedrock provider and model, apply the required actor settings, and verify the connection before production use. The Bedrock actor groups available AWS Bedrock models by provider, including Amazon and third-party model families exposed through the customer’s AWS environment, so the exact options and settings depend on the selected provider and model. This matters because it is the configuration point that determines how Autologyx invokes AWS Bedrock within platform workflows, aligning model access, connection setup, and runtime behaviour with the customer’s AWS configuration.

Catalyst workflow automation ​

Catalyst workflow automation is the Autologyx workflow execution layer used to initiate outbound requests to AI services, orchestrate those interactions within a controlled process, and apply the returned results inside a running workflow. In practice, it is used in AppliedAI patterns such as AppliedAI and the Sequencer, where configuration admins and developers connect workflows to supported AI providers, private model endpoints, customer AI gateways, or custom endpoints through components such as the API Call actor. This matters because it lets teams embed AI-driven extraction, classification, text processing, document conversion, and reusable prompt-based tasks directly into operational workflows while keeping orchestration, control, and process execution inside the Autologyx platform.

ChatGPT Actor ​

The ChatGPT Actor, shown in Autologyx as the OpenAI: GPT or ChatGPT actor, is a native Sequence actor used to send a prompt from a workflow to an OpenAI chat model and use the returned response within the Sequence. It is added to the Sequence canvas like other actors and configured in the actor configuration modal, where administrators or developers define the model, authentication, prompt, context, temperature, and test record. This actor is the standard starting point for language-focused automation tasks such as drafting, classification, summarisation, and language understanding in controlled workflows. It matters because it turns model output into usable workflow data that can be stored, transformed, or passed to later Sequence steps through merge fields and other downstream logic.

check object records hierarchy creation ​

Check object records hierarchy creation is an MCP Work tool in the Autologyx platform that returns the status of an asynchronous Object Record hierarchy creation process. It is used alongside create object records hierarchy to monitor whether a requested hierarchy build has completed and to support follow-on actions that depend on the new parent-child Object Record structure being available. This matters to developers and integrators because hierarchy creation does not complete immediately, so checking its status is essential when orchestrating integrations, sequencing automated work, and retrieving or updating the created records only after the hierarchy has been successfully created.

child Object Class ​

In the Autologyx platform, a child Object Class is an Object Class that is defined as a direct subordinate of a parent Object Class in the platform’s object hierarchy. This relationship is used in Autologyx MCP Work, where tools such as list object class children return the direct child Object Classes available for a specified parent Object Class, and list object class parents returns the corresponding direct parent Object Classes for a child Object Class. Child Object Classes matter to configuration admins and developers because they determine which object structures can be created under another object type, shaping valid parent-child hierarchies for Object Records and supporting correct configuration, integration logic, and hierarchy preparation workflows.

child Object Record ​

A child Object Record is an Object Record that exists in a defined parent-child relationship under a parent Object Record, according to the platform’s Object Class structure. In Autologyx, child records are used to model related data and work items beneath a parent record, such as creating a parent record together with nested child records, finding which child records are linked to a parent, finding which parent records a child is linked to, and removing the relationship between parent and child records. This concept is used in record configuration and in MCP Work tools that navigate, validate, create, and manage related record structures. It matters because child Object Records determine how information is organised, which related record types can be created under a parent, and how agents, users, and integrations work with connected records in the platform.

co pilot agents ​

Co pilot agents are approved AI assistants in Autologyx AppliedAI that work alongside users inside structured workflows, using defined tools to interact with live Autologyx data and services under platform governance. They are used through MCP Work and the Sequencer to support co-pilot style experiences, including helping configuration users and Config Admins plan, architect, design, and build workflows and solutions with Autologyx technology, while drawing on sources such as the Autologyx Knowledgebase and Customer Success experience. Co pilot agents matter because they bring AI assistance into controlled operational processes rather than outside them, with auditability, granular permissions, hard-stop access controls, separation between guidance and live-data-changing actions, and optional human-in-the-loop steps so organisations can enable productive AI support without compromising security, control, or transparency.

co pilot pattern ​

A co pilot pattern is an MCP or MCP Work agent pattern in Autologyx where the agent operates alongside a named user rather than acting independently. It is used in Applied AI and MCP-based implementations, including Autologyx MCP Work, when an agent supports a person as they complete work and can pause to request user confirmation before specific actions continue. This pattern matters because it keeps the user directly involved in execution and decision points, making it a practical starting approach for configuring agent-assisted workflows where human oversight, user context, and controlled action progression are important.

Configurations ​

In the Autologyx platform, Configurations are the settings used to define additional model-specific options for an AI provider integration. They are used in provider setup areas such as AWS Bedrock, where the Configurations section holds the parameters required to tailor how a selected model is used by the platform. This matters to configuration administrators and developers because these settings control the behavior and compatibility of the model within Autologyx, ensuring the provider, actor, and model are configured correctly for use with AI features in the Sequencer.

controlled autonomous workflows ​

Controlled autonomous workflows are Autologyx workflows in which approved agents perform defined work within the platform autonomously under configured permissions, tool access, and risk controls, without requiring a user to act alongside them at each step. In practice, this term is used in the context of Autologyx MCP Work and solution design, where administrators and advanced designers decide how agents can operate, what tools they can use, and what governance boundaries apply. Controlled autonomous workflows matter because they let organisations extend automation beyond user-assisted co-pilot interactions while maintaining security, compliance, and operational control through deliberate configuration of permissions, approved agent behaviour, and oversight mechanisms.

create object record ​

Create object record is an MCP Work tool in the Autologyx platform that creates a new Object Record, giving developers and integrators a programmatic way to add a single record to the object model used by a work solution. It is used in MCP-based integrations and automation when an external service or custom implementation needs to create an individual record directly, rather than creating a full parent-and-child structure in one operation. This matters because Object Records hold the structured business data that processes, services, and related records depend on, so using create object record correctly is a fundamental step when building integrations that populate or extend Autologyx object data.

create object records hierarchy ​

Create object records hierarchy is an MCP Work tool in the Autologyx platform that starts an asynchronous process to create a parent Object Record together with its nested child Object Records in a single hierarchy. It is used by developers, integrators, and configuration administrators when a business object must be created with its related child Object Classes and child Object Records as one structured operation rather than as separate record-creation steps. This matters because it provides a consistent way to establish complete object relationships from the outset, supports integrations and automated workflows that need to submit hierarchical data, and works with the corresponding hierarchy creation status check to manage processing that completes asynchronously.

custom Object Class fields ​

INSUFFICIENT_EVIDENCE

dedicated actors ​

Dedicated actors, also called native AI actors, are platform-provided actors in Autologyx Catalyst that deliver native connectivity and configuration for commonly used AI providers within Sequencer-driven workflows. They are used when configuring AI interactions in the platform, offering a built-in setup experience instead of relying solely on generic integration patterns such as an API Call actor or external service orchestration. Dedicated actors matter because they simplify common provider integrations, reduce configuration effort for administrators and developers, and help standardize how AI services are invoked as part of workflow automation.

dedicated AI actor ​

A dedicated AI actor, also referred to as an AI actor, is a purpose-built actor in an Autologyx Sequence that connects directly to a supported AI service, such as the standard OpenAI, Azure OpenAI, or AWS Bedrock actors, rather than using the platform’s generic API integration capability. It is used when configuring Sequences in the Sequencer to invoke AI models through a packaged actor designed for that provider or service. This matters to configuration admins and developers because it determines how AI functionality is implemented in a workflow: supported services can be added through dedicated actors, while privately hosted or otherwise unsupported models are connected by using an API Call actor or other generic API integration approach instead.

deterministic Sequence logic ​

Deterministic Sequence logic is the fixed, rule-based workflow logic configured in an Autologyx Sequence to control how steps run, how data is validated and transformed, and how downstream actions are triggered without variability in execution. It is used in Sequence design and integration scenarios, particularly when combining AI-driven steps with standard workflow automation, API Call actors, and structured outputs that must be parsed and acted on reliably. This matters because deterministic Sequence logic provides the predictable orchestration layer around non-deterministic model responses, helping configuration admins and developers enforce validation rules, route work consistently, and ensure later workflow steps operate on controlled, machine-usable data.

document automation ​

Document automation in the Autologyx platform is the capability used to create and manage documents as part of live operational work within an existing process. It is used alongside activities such as finding records, updating data, managing tasks, and navigating record relationships, and is exposed in areas such as Autologyx MCP Work where documents form part of the work being carried out. This matters because it lets end-users produce the required documents in context, while configuration admins and integrators can embed document-driven steps into controlled workflows that benefit from Autologyx data structures, permissions, and auditability.

document generation ​

Document generation in the Autologyx platform is the process of creating a document for an Object Record from a configured document template and then making the resulting generated document payload, metadata, status, and download information available through Autologyx MCP Work tools. It is used in agent-enabled workflows through the generate object record document, get object record document, and download object record document capabilities, allowing approved agents and integrations to start generation, monitor processing, and retrieve the finished output where permissions allow. This matters to developers, integrators, and configuration admins because it connects template-driven document production to record data and operational workflows, supports automated and human-reviewed communications and outputs, and requires correct tool enablement, permissions, and customer configuration to control how documents are produced and accessed.

document template ​

A document template in the Autologyx platform is a configured template used to generate documents for a specific Object Class and, in practice, for a specific Object Record. It is used in document generation features across the platform, including Sequences that apply a template as part of workflow automation and Autologyx MCP Work tools that search document templates, retrieve template details, and start document generation by supplying an Object Record ID and Document Template ID. Document templates matter because they connect platform data to repeatable document outputs, allowing configuration admins and integrators to define standardised generation behaviour and enabling end-users and approved agents to produce the correct document directly from the relevant record as part of operational work.

document URL ​

A document URL in Autologyx is the URL returned in document metadata for a generated or completed document, used by integrations and MCP Work tools as the source from which the document UUID is extracted. It appears in tool outputs alongside processing status and other metadata, and it is a required intermediary when a workflow needs to download the file for a completed document, because the UUID from that URL is then supplied to the download object record document operation. This matters to developers and integrators because document retrieval depends on handling the document URL correctly: it links document generation output to the subsequent API call that fetches the actual file.

document UUID ​

In Autologyx, the document UUID is the unique identifier for a generated document instance and is used by developers and integrators when calling MCP Work tools that need to retrieve or download a specific document file. It is not entered manually as a business field; instead, it is extracted from the document URL returned in document metadata, then passed with related identifiers such as the Object Record ID and Document Template ID to the relevant service call. This matters because the document UUID is the key that links API operations to the exact document instance, ensuring that downstream automation, file retrieval, and integration workflows act on the correct completed document.

download object record document ​

In the Autologyx platform, download object record document is an MCP Work tool used to retrieve a generated document that belongs to an Object Record, including both the document file payload and its associated metadata. It is used by developers and integrators in workflows that generate documents from Object Records, typically after creating records or record hierarchies and obtaining the relevant document identifier or URL. This tool matters because it provides the final access step for consuming generated output in downstream systems, enabling integrations to collect, store, transmit, or present the exact document produced by an Autologyx process together with the metadata needed to identify and manage it correctly.

Email Intake Object Class ​

Embedding Model Actors ​

field aliases ​

Field aliases are the canonical key names used by Autologyx MCP Work to identify Object Class fields when creating, updating, or filtering Object Records. In MCP Work tools, field values are passed using these aliases rather than display labels, and the platform provides a tool to list the valid fields and aliases for a specific Object Class so the correct keys can be used. This matters to developers, integrators, and configuration admins because record operations depend on supplying valid aliases for the target Object Class; using the correct aliases ensures data is written to and read from the intended fields and supports reliable automation and integration behaviour.

field slug ​

In the Autologyx platform, a field slug is the stable identifier used to reference a field in configuration-driven and integration contexts, rather than the field’s display label. It is used when defining or consuming create and update operations, including MCP Work tools, where tool aliases are normally derived from the field slug value without its prefix. Field slugs matter because they provide a consistent, implementation-level name for fields across configuration and automation, helping developers, integrators, and configuration administrators map data correctly, build reliable object record operations, and avoid ambiguity when display names change.

generate object record document ​

Generate object record document is an MCP Work tool in the Autologyx platform that starts document generation for a specific Object Record using a selected Document Template. It is used by developers and integrators when automating work that produces platform documents from record data, typically as part of a workflow or service interaction that creates, retrieves, or distributes generated outputs. This matters because it is the action that initiates creation of the document asset tied to a business record, forming the link between structured object data and the final generated file that can then be identified, accessed, or downloaded through related document URL or document UUID operations.

generic API actors ​

Generic API actors are Autologyx actors used to make direct HTTP API calls to external services when a native actor does not provide the required capability or level of control. In the platform, they are configured and used by administrators and developers within workflow and integration designs to call provider-specific endpoints directly, including advanced OpenAI endpoints that sit outside the standard OpenAI actor experience. This matters because generic API actors give integrators a flexible way to extend Autologyx with custom request handling, endpoint access, and provider features, while still operating within the platform’s actor-based automation model.

generic API integration capability ​

In Autologyx, the generic API integration capability is the platform pattern for connecting a Sequence to an external HTTP-based service without requiring a dedicated purpose-built actor. It is used within workflow design and configuration, typically through an API Call actor or a similar integration pattern, to send structured requests to an endpoint, authenticate using an Authentication Object where required, and consume the returned data later in the workflow. This capability is especially relevant when integrating privately hosted models or other external services that are not covered by a native Autologyx actor. It matters because it gives configuration admins and developers a flexible, reusable way to extend platform workflows, orchestrate external processing from the Sequencer, and bring structured responses back into Sequences for downstream automation.

get document template ​

Get document template is an MCP Work tool in the Autologyx platform that retrieves the details of a single Document Template. It is used by developers, integrators, and configuration administrators when they need to look up a template by its identifier and inspect the template definition that supports document generation in a workflow. This matters because Document Templates control how generated documents are structured and referenced, so being able to retrieve a specific template is essential for validating configuration, supporting integrations that depend on template metadata, and linking document generation processes to the correct template, document UUID, document URL, or related document download actions.

get object class ​

In the Autologyx platform, get object class is an MCP Work tool used to retrieve the details of a single Object Class, which is a core configuration element that defines a business object and its structure within the configuration experience. It is used by developers, integrators, and configuration administrators when they need to inspect the definition of a specific Object Class, including information relevant to related concepts such as child Object Class relationships. This matters because Object Classes underpin how data structures and configurable business objects are defined in Autologyx, so being able to retrieve an individual Object Class accurately supports configuration review, integration work, and administration tasks.

get object record ​

Get object record is an MCP Work tool in the Autologyx platform that retrieves the details of a single Object Record. It is used by developers and integrators when a workflow, service, or external integration needs to read the current data for a specific record in order to inspect its fields, confirm its state, or use that information in subsequent automation steps. This tool is part of the Object Record lifecycle alongside actions such as creating records, building record hierarchies, and retrieving Object Record document information. It matters because it provides the authoritative record-level data needed to drive process logic, validate outcomes, and connect Autologyx business objects with external systems.

get object record document ​

Get object record document is an MCP Work tool used to retrieve the details of a generated Object Record document in the Autologyx platform. It returns the document’s metadata, current generation status, and download information, such as the document UUID and document URL, so developers and integrators can check whether document generation has completed and obtain the information needed to access the output. This tool is typically used after creating an object record or initiating document generation, and it matters because it provides the programmatic link between a platform record and the generated document that downstream services, integrations, or user-facing processes need to fetch and use.

governance gateway ​

The governance gateway in the Autologyx platform is the central control layer used with MCP services to determine what an MCP-enabled agent can access and do. It is used when configuring Autologyx MCP integrations alongside permissions, MCP mappings, user accounts, user groups, and the MCP tool catalogue, providing finer-grained control than connector-level restriction settings in the agent client alone. This matters because it allows configuration and security administrators to govern tool and data access consistently within Autologyx, helping ensure agents operate only within the actions, services, and visibility that the platform configuration explicitly allows.

hard stop gated control ​

Hard stop gated control is an AppliedAI governance mechanism in the Autologyx platform that enforces non-bypassable access boundaries for both agents and users at every level of the platform. It is used when configuring and operating AI-assisted activity, including co-pilot, autonomous, and headless agent patterns, to ensure access and actions are constrained by defined permissions and security policies. In practice, it works alongside granular permissions, human-in-the-loop controls, and the separation of read-only guidance from live data changes, so configuration admins and super admins can limit what can be seen or done by agent, instance, client, matter, or individual record. This matters because it provides enterprise-grade control over AppliedAI behaviour, helping organisations protect sensitive data, enforce compliance requirements, and maintain safe, governed agentic workflows.

headless agents ​

In the Autologyx platform, headless agents are Applied AI–driven autonomous agents that perform tightly controlled work without direct user interaction when that operating model is enabled. They are used within Applied AI and related agentic workflow designs to execute defined tasks under configured permissions and control boundaries, typically for work that does not require a human-in-the-loop step. This matters to Configuration Admins, Developers, Integrators, and Super Admins because enabling and designing headless agents affects how work is automated, what permissions the agent can act under, and how safely autonomous activity is constrained within the platform.

human in the loop ​

In the Autologyx platform, human in the loop describes a governance and workflow pattern in AppliedAI where a person is deliberately placed at defined decision points to review, approve, or complete steps before actions continue, especially when those actions could affect live data or process outcomes. It is used when configuring AI-assisted, co-pilot, or autonomous agent experiences and sequencing workflows so that important decisions include mandatory user intervention rather than running end to end without oversight. This matters because it lets Configuration Admins and Super Admins combine automation with enterprise control, applying hard-stop gates, permissions, and approval checkpoints to meet security, compliance, and operational requirements while keeping accountability for high-impact actions.

human review task ​

A human review task is a task created within an Autologyx Sequence to route work to a person for manual assessment before the workflow continues or a result is used. It is used on the Sequence canvas as a review gate, often after an actor such as an AI or Local Variable step has produced an output that requires validation, completion, or approval. Human review tasks are particularly important when responses are incomplete, unexpected, difficult to validate automatically, or intended for important decisions, external communications, or final record updates. For configuration admins, they provide a controlled way to design guardrails and exception handling into automated workflows; for end-users, they define where manual action is required; and for compliance, security, and analytics teams, they help ensure that high-impact or semantically generated outputs are subject to appropriate oversight.

JSON variable ​

A JSON variable in the Autologyx platform is a variable type used to store structured data in valid JSON format so that multiple named values can be captured and reused as a single variable. It is configured when defining variable outputs for actors, including the OpenAI: GPT actor, where the variable name is set, the type is selected as JSON, the source is the actor response, and the value maps the JSON fields to include. JSON variables are primarily used by configuration administrators and developers or integrators when an actor returns structured content that needs to be preserved for downstream processing, mapping, or display. This matters because choosing the JSON type enables Autologyx to work with nested or multi-field output in a consistent format, making it easier to pass structured responses between actors and reference the data in platform configuration.

list object class children ​

In the Autologyx platform, list object class children is an MCP Work tool that returns the direct child Object Classes defined beneath a specified parent Object Class. It is used by developers, integrators, and configuration administrators when working with the Autologyx configuration experience to inspect and validate object hierarchies, especially when building or supporting create object records hierarchy and related hierarchy-checking operations. This matters because Object Class parent-child relationships determine how structured records are organised and created in the platform, so being able to retrieve child classes directly helps ensure configurations, integrations, and hierarchy-driven processes are aligned with the intended data model.

list object class fields ​

List object class fields is an MCP Work tool in the Autologyx platform that returns the valid fields and field aliases defined for a specific Object Class. It is used by developers, integrators, and configuration administrators when building or configuring automations, integrations, and record-creation logic that interact with object data. This tool is especially important when working with related capabilities such as creating object records, creating object record hierarchies, or validating hierarchy creation, because it identifies the exact field names and supported aliases that must be used for the target Object Class. Using list object class fields helps ensure that object payloads and mappings align with the class definition, reducing configuration errors and enabling accurate object record handling across the platform.

list object class parents ​

In the Autologyx platform, list object class parents is an MCP Work tool that returns the direct parent Object Classes for a specified child Object Class. It is used by developers, integrators, and configuration administrators when working with Object Class structures, especially where record hierarchies and parent-child relationships must be understood or validated. This tool is relevant during configuration and integration tasks that depend on the defined Object Class hierarchy, including creating object records in the correct hierarchy and supporting processes that create or check Object Record hierarchy relationships. It matters because it provides the authoritative parent-class lookup needed to navigate, configure, and troubleshoot Object Class inheritance and hierarchy-driven behavior in the platform.

live operational work ​

Live operational work in Autologyx is the execution of day-to-day work on active records and tasks within an existing process, rather than platform setup or product configuration. It is used in the context of Autologyx MCP Work, where approved AI assistants and agents support users with live operational activity such as finding records, reading and updating data, managing tasks, using document automation, navigating record relationships, and progressing work through controlled autonomous or co-pilot operating patterns. This matters because it defines the boundary for agentic action in the platform: MCP Work is designed to interact with production work safely and usefully, helping developers, integrators, and end-users understand when AI tools should be applied to operational execution instead of configuration changes.

Local Variable actor ​

A Local Variable actor is a Sequencer actor used on the Sequence canvas to capture, store, and extract values from the output of another actor, such as an OpenAI or Azure OpenAI actor. It is configured in the actor configuration modal and is commonly placed after an actor that returns text or JSON so the response, or specific parts of it, can be saved as reusable values and referenced later through merge fields or subsequent workflow logic. This matters because it turns actor output into structured data the platform can reliably reuse for downstream steps such as updating records, routing the workflow, composing documents or messages, invoking further parsing, or preparing content for human review.

lookup suffixes ​

Lookup suffixes are field-specific filter operators appended to a field slug when querying records through Autologyx MCP Work tools, allowing developers and integrators to refine how a filter matches values for a given field type. They are used in tool requests that support filtering, including record retrieval operations such as get object record and get object class, and work alongside concepts such as field aliases and field slugs to target the correct data. Lookup suffixes matter because they control the behavior of comparisons in API and tool queries—for example, enabling exact matches, partial matches, range-style checks, or other supported field-type-specific lookups—so using the correct suffix is essential for returning the intended records and building reliable integrations.

Loop Actor pattern ​

The Loop Actor pattern is a Sequencer design pattern in Autologyx used to run the same operation repeatedly across a set of items and aggregate the results into a single flow. In the AppliedAI context, it is used when multiple playbook functions must be executed against the same source content: the Sequence repeats the AI request for each function and collects the outputs for downstream processing. This pattern matters to configuration admins and developers because it provides a structured way to orchestrate repeated actor execution without duplicating sequence logic, making multi-function AI processing easier to configure, maintain, and integrate with related components such as dedicated actors and API Call actors.

Loop actors ​

Loop actors are Sequencer actors in the Autologyx platform that execute a defined action repeatedly across a set of items, records, or task iterations within a workflow. They are used when configuring automation patterns that need the same logic applied multiple times, such as running reusable prompt functions with playbook-style Object Classes or performing repeated extraction and classification steps when integrating AI services through the API Call actor. Loop actors matter because they let configuration admins and developers structure scalable, reusable workflow logic, reduce duplication in playbook design, and reliably orchestrate batch-style processing across repeated workflow inputs.

Manual Task ​

A Manual Task in the Autologyx platform is a user-performed work item created against an Object Record, typically through Autologyx MCP Work services or platform configuration, to capture a step that requires human action rather than automated execution. It is used wherever a process needs an assignee to review, complete, or progress work in the context of a specific record, linking that activity directly to the underlying business object. This matters because Manual Tasks provide a structured way to introduce human intervention into automated workflows, ensure work is tracked at record level, and enable developers, configuration admins, and end-users to coordinate operational steps alongside Automatic Tasks within a single process.

MCP enabled agent ​

MCP mappings ​

MCP mappings are the Autologyx configuration controls that define how access to MCP services and tools is applied within the platform alongside the user account, user groups, and the standard Autologyx permission model. Used when setting up and governing MCP-enabled agents and their access to the MCP tool catalogue, MCP mappings form part of the access-control layer that determines what an agent can see and do. They matter because they let configuration and security administrators enforce structured, platform-level governance over external tool access, helping align agent behaviour with organisational permission, compliance, and governance requirements.

MCP services ​

MCP services are an AppliedAI pattern in the Autologyx platform that let approved AI assistants and agents connect to Autologyx through governed tools and APIs. They are used when the interaction starts outside Autologyx, with the assistant or agent initiating requests to read records, work with tasks, retrieve knowledge, or perform other controlled actions against enabled services such as MCP Work, with access constrained by the MCP service, platform permissions, and customer configuration. This matters to developers, configuration administrators, and security or compliance teams because MCP services define how external AI clients are connected to Autologyx, which service family is exposed for a given purpose, and how tool-level access is controlled to support secure, policy-aligned agentic workflows.

MCP Success ​

MCP Success is the Autologyx Applied AI capability that provides approved AI assistants with access to the Autologyx Knowledgebase and Customer Success guidance so they can help users plan, design, and configure effective solutions. It is used in guidance-led interactions across Applied AI, especially where users need product knowledge, design recommendations, implementation planning, and configuration support rather than execution against live work. MCP Success matters because it gives end-users and configuration administrators a controlled way to obtain platform-specific expertise inside Autologyx, and it is distinct from MCP Work: MCP Success supports knowledge, planning, and solution design, while MCP Work operates on live data and tasks.

MCP tool catalogue ​

The MCP tool catalogue is the list of MCP tools available to an MCP enabled agent in the Autologyx platform, including descriptions of what each tool is used for. It is used within Autologyx MCP Work and related MCP services so the agent can identify the tools it has access to and select the correct one when completing a task. For developers, integrators, and configuration admins, the catalogue matters because it defines the operational capabilities exposed to the agent, supports correct tool selection and configuration, and provides the reference point for understanding which MCP-powered actions are available in a given implementation.

MCP Work ​

MCP Work is the Autologyx capability that exposes a controlled set of tools for approved AI assistants and agents to interact directly with live work in the platform. It is used in Applied AI scenarios where an assistant needs to perform operational actions such as creating object records, building or checking record hierarchies, downloading object record documents, or supporting document generation, while explicitly not providing access to Autologyx configuration tools. MCP Work matters because it connects AI-driven interactions to real platform activity, so access is governed through tool permissions and must be configured carefully to ensure agents can perform only the specific actions they are authorised to carry out.

MCP Work tools ​

MCP Work tools, also called MCP tools or the tool catalogue, are the set of Autologyx MCP Work capabilities that approved AI assistants and agents use to interact with live work in the Autologyx platform. They are documented in the MCP Work reference pages and are primarily used by developers, integrators, and configuration administrators who need to understand which actions an agent can perform, such as working with records and tasks. Access to these tools is controlled per agent, so an agent can only use the specific MCP Work tools it has been granted under the platform’s role-based access model. This matters because MCP Work tools enable real actions in Autologyx, making correct tool selection, permissions design, and governance essential when configuring safe and effective agent access.

Merge fields ​

Merge fields are placeholders and expressions used in Autologyx configuration to insert values from the record being processed into actor inputs and related text fields at runtime. They are used most visibly in Sequencer-based actor configurations such as OpenAI, Azure OpenAI, and AWS Bedrock prompts, messages, context, and value inputs, where static text is combined with record data, extracted document text, email content, or specific response attributes. Merge fields matter because they make prompts and integrations dynamic and record-specific, allowing configuration admins, developers, and end-users to tailor processing to each Object Record and to test configurations accurately by supplying a Record ID so the platform can resolve the referenced data.

ML and AI tab ​

Model ​

In Autologyx, a Model is the specific foundation model selected to process an AI request within a workflow, such as when a Sequence uses the AWS Bedrock integration to call a model through Amazon Web Services. Configuration admins choose the model as part of actor or integration setup, where it determines which provider-backed model family handles prompts and returns results to the Sequencer. This setting is used anywhere Autologyx supports configurable AI execution through a provider, and it matters because it directly controls the behaviour, compatibility, governance route, and regional availability of AI processing in the platform.

model agnostic orchestrator ​

A model agnostic orchestrator in Autologyx is the platform role performed by Autologyx Catalyst and AppliedAI within the Sequencer, where Autologyx coordinates AI-augmented processing without being tied to a single underlying model provider or model type. It is used in agentic workflows and AI-enabled process design to route work between sequencing logic, AppliedAI capabilities, API Call actors, and connected services such as MCP services, allowing administrators and integrators to configure workflows that invoke different AI services through a consistent orchestration layer. This matters because it lets configuration admins, developers, and super admins design and evolve AI-driven automations with greater flexibility, provider independence, and maintainability while keeping orchestration, control, and process execution inside the Autologyx platform.

native actor ​

In Autologyx, a native actor, also called a dedicated actor, is a built-in actor created for a specific external capability or provider and exposed through the platform as a purpose-designed integration rather than a fully generic API call. Native actors are used when configuring Sequence steps and actor settings, including provider-specific options such as the ChatGPT Actor or OpenAI Embedding Actors, and are managed through the actor configuration experience. They matter because they provide a simpler, more guided way to use supported services in the platform, but with a defined set of exposed endpoints and options; when a required endpoint, request option, or response pattern is not available in a native actor, administrators and integrators use generic API actors instead for direct control.

Object Class ID ​

Object Class ID is the integer identifier for an object class in the Autologyx platform, used by record-focused tools and APIs to specify which class a new record belongs to, which parent or child class is being referenced in hierarchy creation, or which class should be inspected before working with its records. It is commonly required when using MCP Work tools such as creating object records, creating object record hierarchies, and checking hierarchy creation, and it is distinct from an Object Record ID, which identifies an individual record instance. This matters to developers, integrators, and configuration administrators because the correct Object Class ID determines the schema, available fields, templates, and relationships that the platform applies, ensuring records are created and processed against the intended class definition.

Object Classes ​

Object Classes are the core data-model definitions in the Autologyx platform that define a type of business record, its available fields and field aliases, and its parent-child relationships to other classes and records. They are used throughout Catalyst configuration and runtime activity: Sequences reference an Object Class to read and update record data, AI and API call patterns use Object Classes to supply prompt and context data, and playbook-style Object Classes can be used to store reusable workflow or prompt functions. Object Classes also underpin MCP Work interactions, where tools search classes, retrieve class details, inspect valid fields, and navigate child and parent Object Class structures before working with Object Records. They matter because they provide the structural foundation for forms, automation, integrations, and record handling, so configuring them correctly is essential for a usable data model, reliable workflow behaviour, and effective administration.

Show 3 more pages

Object Record document ​

An Object Record document in the Autologyx platform is a generated document associated with a specific Object Record, created from a Document Template and managed through MCP Work tools. It is used in developer and integration workflows that generate documents, retrieve their metadata and status, download the document payload, and search documents linked to an Object Record. This term matters because it represents the document output of an Object Record process, identified and handled through document-specific operations such as generation, retrieval, and download, enabling integrations to track document creation and access the resulting files and metadata reliably.

Object Record hierarchy ​

Object Record hierarchy in the Autologyx platform is a structured set of related Object Records created as a parent record with one or more nested child Object Records, typically aligned to parent and child Object Classes. It is used in MCP Work tools that create object records hierarchy in a single asynchronous operation and in status-check tools that track completion of that hierarchy creation process. This matters to developers, integrators, and configuration admins because it enables complex business data structures to be created consistently in one request, preserves relationships between records from the point of creation, and supports automated workflows that depend on correctly linked parent and child records.

Object Record ID ​

Object Record ID is the unique identifier for a specific Object Record in the Autologyx platform and is used by tools and integrations to target an existing record for retrieval, update, document generation, document download, and relationship management. In MCP Work and related platform operations, it is commonly supplied as a required input on its own or alongside an Object Class ID, and it is also used when linking parent and child Object Records in hierarchy creation and other record-relationship actions. This identifier matters to developers and configuration admins because it ensures the correct record is addressed by automations and API-driven actions, and because many operations only succeed when the referenced record already exists and is visible to the calling agent or service.

Object Records ​

Object Records are the individual data records in Autologyx that hold the structured information for a business item or case within an Object Class, and they act as the system record that workflows, tasks, documents, integrations, and AI features work against. They are used throughout the platform in Sequences, user-facing processes, and MCP Work, where users and approved agents can find, read, create, update, relate, and manage records, including parent and child record structures and record-related documents. Object Records matter because they provide the live operational context for processing work: Sequence actors can collect data from a source record, use merge fields to tailor prompts or integrations to that specific record, store outputs back onto the record, and route downstream actions, while administrators and integrators rely on Object Class IDs, Object Record IDs, and field aliases to configure and automate record operations consistently.

Show 5 more pages

OpenAI ​

OpenAI Embedding Actors ​

OpenAI Embedding Actors are Autologyx actors that call OpenAI embedding models to convert text into vector embeddings for use in workflows that need meaning-based search, comparison, matching, or retrieval. They are used in Applied AI and Sequencer configurations wherever record text must be transformed into a searchable representation, such as supporting semantic search, retrieval-augmented workflows, similarity detection across records, clauses, requests, or documents, and producing vector-ready output for downstream processing. Configuration is managed in the OpenAI embeddings configuration modal, where administrators and integrators define the model, authentication, input text, output format, dimensions, and test record. OpenAI Embedding Actors are distinct from OpenAI GPT or ChatGPT actors because they generate vector representations rather than conversational or generated text, which makes them essential when designing workflows that depend on embedding-based retrieval and comparison.

OpenAI embeddings configuration modal ​

The OpenAI embeddings configuration modal is the Autologyx actor configuration interface used to set up an OpenAI Embedding Actor. In this modal, configuration and Super Admin users define the embedding model, select the Authentication Object used to connect to OpenAI, specify the input text—often using merge fields from Object Records—choose the output format, set dimensions, and provide a test record such as a Record ID for validation. It is used when configuring applied AI workflows that generate embeddings through OpenAI, and it matters because these settings control how source record data is transformed into embedding output and ensure the actor is correctly connected, tested, and ready for use in the platform.

OpenAI: GPT actor ​

The OpenAI: GPT actor is an Applied AI actor in Autologyx Catalyst that adds ChatGPT-powered processing to a Sequence. Configuration admins and developers use it in the Sequence builder by dragging it onto the canvas from the ML and AI tab and connecting it to workflow triggers, with prompts configured dynamically through merge fields that pull data from records. It is available as a premium OpenAI integration enabled through subscription setup, and it is used wherever a workflow needs GPT-driven output as part of its automated steps. This matters because it allows organisations to embed AI-generated responses and prompt-based processing directly into business workflows, making Sequences more context-aware, flexible, and capable of handling tasks that depend on record-specific inputs.

OpenAI: GPT or ChatGPT actor ​

The OpenAI: GPT or ChatGPT actor is an Autologyx Sequence actor that sends a prompt to an OpenAI chat model and returns the model’s response for use within the workflow. It is used by adding the actor to a Sequence like any other actor, then configuring it in the actor configuration modal with the required model, Authentication Object, prompt, context, temperature, and test record; prompts can also incorporate Merge fields so the request is populated with workflow data. This actor is the standard starting point for language-based automation tasks such as understanding, drafting, classification, and summarisation, and it matters because its output can be stored, transformed, and passed to later Sequence steps to drive controlled, repeatable process automation.

parent Object Class ​

In the Autologyx platform, a parent Object Class is an Object Class that sits directly above another Object Class in the configured class hierarchy, defining the immediate parent-child relationship used when working with related records. This term is used in Autologyx MCP Work, particularly through the list object class parents tool, which returns the direct parent Object Classes for a specified child Object Class, and alongside the corresponding child lookup tools that navigate the hierarchy in the opposite direction. Parent Object Classes matter to Configuration admins, Developers / Integrators, and Super Admins because they are essential for understanding valid object relationships, navigating the platform’s data model, and ensuring integrations or automated processes use the correct class structure when identifying related records and creating or managing child records.

parent Object Record ​

A parent Object Record is the record at the top of an Object Record relationship in Autologyx, used to contain, organise, and link one or more child Object Records within a defined Object Class hierarchy. It is used in Autologyx MCP Work tools that create object record hierarchies, find child records linked to a parent record, find parent records linked to a child record, and remove parent-child relationships. For end-users, configuration admins, and developers or integrators, the parent Object Record matters because it defines the container record that child records sit under, drives how related records are structured and retrieved, and is a key input when configuring or automating hierarchical record creation and management across the platform.

playbook functions ​

Playbook functions, also described as playbook style prompt functions, are reusable units of AI prompt logic used in Autologyx to run consistent extraction, classification, summarisation, and review tasks against a document or record. In practice, they are commonly stored on an Object Class so the same function definitions can be reused across processes, while a Sequence invokes them as part of an AppliedAI workflow. They are especially useful when prompt logic needs to be managed separately from Sequence design, such as in contract review where individual functions extract specific fields or checks like parties, term, governing law, liability caps, or missing clauses. Where several functions must be applied to the same source content, the Sequencer can run them repeatedly, for example through a Loop Actor pattern, and collect the outputs into structured record data or draft results for review. This matters to configuration admins and developers because playbook functions improve reuse, standardisation, and maintainability of AI-enabled automation.

playbook style Object Classes ​

In Autologyx, playbook style Object Classes are Object Classes designed to encapsulate reusable playbook logic as callable functions, allowing common patterns such as AI prompt construction and related request handling to be defined once and reused across workflows. They are used in solution design alongside the Sequencer and actors such as API Call, where a process needs consistent, repeatable logic for outbound service interactions. This matters to configuration admins and developers because it improves maintainability, standardises implementation across playbooks, and reduces duplication when building integrations or reusable automation components.

Private Cloud Ai ​

Privately hosted models ​

Privately hosted models are AI or machine learning services that Autologyx Sequences call when the model is hosted, managed, or controlled outside the platform’s standard OpenAI, Azure OpenAI, or AWS Bedrock actors. In Autologyx, they are used through the platform’s generic API integration capability and are typically configured by admins or integrators using authentication and API call components so Sequence and Sequencer logic can send data to customer-specific endpoints and consume structured responses. This approach supports a wide range of services, including large language models, specialist models, image or audio models, redaction services, named entity recognition, and AI gateways. Privately hosted models matter because they give organisations greater control over hosting, access, logging, routing, and data handling, while enabling model behaviour that is tailored to specific document types, terminology, risk taxonomies, clause libraries, intake categories, matter types, internal playbooks, and historic decision data.

Provider ​

In Autologyx, a Provider is the model vendor selection used in AI configuration fields such as the AWS Bedrock actor, where it determines which group of AI models is available in the Model field. For configuration admins, Provider is used when setting up Sequences to call models through AWS Bedrock, with options reflecting the model providers enabled in the customer’s AWS and Autologyx environment, such as Amazon, Anthropic, Meta, Mistral, or OpenAI. This matters because the selected Provider controls the model families users can choose from and helps align AI usage with the organisation’s AWS region, access controls, governance, and approved private-cloud integration settings.

Public AI Providers ​

Record Fields ​

Record Fields are mergeable placeholders that represent values held on a record in the Autologyx platform and can be inserted into configurable inputs where record-specific data is needed. They are used in places such as actor configuration, including prompt text in the OpenAI: GPT actor, where users can right-click to insert a field token such as {{record.field\ email\ from}} directly into the input. Record Fields matter because they let end-users and configuration admins dynamically pass data from the current record into automated steps, ensuring actors and workflow components use the correct contextual information for each transaction.

record hierarchy creation ​

Record hierarchy creation is the Autologyx asynchronous process that creates a parent Object Record together with its nested child Object Records in a single hierarchy, typically aligned to the relevant parent and child Object Classes. It is used in Autologyx MCP Work services where integrations or platform configurations need to submit and then check the status of hierarchy creation as a background operation rather than creating each record individually. This matters because it enables developers and configuration administrators to build complete structured business objects efficiently, preserve parent-child relationships consistently, and manage long-running or bulk creation tasks through status-driven processing.

record hierarchy creation process ​

Record ID ​

Record ID is the identifier of a specific Autologyx object record that you supply when testing configurations whose prompt, message, context, or input text contains merge fields. It is used in Test Integration and related test screens for AI and actor configurations, such as OpenAI, Azure OpenAI, AWS Bedrock, and embedding setups, so the platform can resolve merge fields against real record data during the test. This matters to configuration admins and developers because without a valid Record ID, any test that depends on record-backed values cannot evaluate the final populated input correctly, making it harder to validate prompts, outputs, and integration behaviour.

Record Properties ​

INSUFFICIENT_EVIDENCE

record relationships ​

Record relationships are the configured links between Autologyx records that define how parent and child records are connected within a process or case structure. In the platform, these relationships are used when users, administrators, and integrations need to navigate from one record to its related records, create related record structures, and work across connected data as part of live operational activity. They are especially relevant in capabilities such as Autologyx MCP Work, where approved tools can find records, read and update data, and move between parent and child record relationships to support end-to-end work. Record relationships matter because they organise information into meaningful business structures, enable downstream tasks and automation to operate in the correct context, and ensure that related work is handled consistently across the platform.

record tool endpoints ​

Record tool endpoints are the MCP Work service endpoints in Autologyx that provide agent and integration access to Object Record operations, including inspecting the data model, locating and working with Object Records, managing parent-child record relationships, and using document automation features such as document generation and record document download. They are used within MCP Work tooling and are especially relevant when configuring or building integrations that create records, create record hierarchies, validate asynchronous hierarchy creation, and handle related documents through template-driven processes. These endpoints matter because they expose the core record-level actions needed to interact with business data in Autologyx in a structured, automatable way, supporting both operational workflows and configuration-driven solutions.

record tools ​

Record tools, also described as Record tool endpoints, are the Autologyx MCP Work capabilities that let an approved agent search for, read, create, update, and relate Object Records, as well as work with documents associated with those records. They are used within the MCP Work service by developers and integrators who configure agent access to business data and record-driven actions across Object Classes, child Object Records, and document-related processes such as document generation from templates. Record tools matter because they provide the controlled integration surface through which agents interact with core Autologyx records and their documents, enabling automation that is consistent with the platform’s data model and operational workflows.

remove object record child ​

In the Autologyx platform, remove object record child is an MCP Work tool used to delete the parent-child relationship between two Object Records without describing any broader object creation or hierarchy-building action. It is used in integrations and configuration-driven automations wherever Object Record hierarchies are maintained, especially after records have been linked through hierarchy creation processes. This tool matters because Object Record relationships control how related business data is structured and navigated across the platform, so removing an incorrect or obsolete child link helps administrators and integrators keep object hierarchies accurate and aligned with the intended Object Class design and process behaviour.

reusable prompt functions ​

Reusable prompt functions are playbook-style Object Classes in Autologyx that encapsulate prompt content and related request-building logic so it can be invoked consistently from Sequencer flows, typically through the API Call actor when integrating with external AI services. They are used by configuration admins and developers to centralise prompt definitions, standardise how prompts are assembled and passed in outbound REST requests, and support repeated use across multiple playbooks or loop-driven processing patterns. This matters because it improves maintainability, reduces duplication, and makes AI-enabled automations easier to update, govern, and reuse within configurations that are marked for broader access, such as Public or Unrestricted assets.

role based access model ​

  • Mostly relevant to: Configuration admins, Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
  • Closely related concepts: Autologyx MCP Work

The Autologyx role based access model is the platform’s standard authorisation framework that determines what a user, service account, process, or agent can see and do in Autologyx according to its assigned role. In the context of Autologyx MCP Work, it is used alongside tool exposure, account selection, and user context to enforce access boundaries, ensuring that agents and integrations only operate within the permissions granted by the platform. This matters when configuring MCP Work, service accounts, and agent-enabled processes because the role based access model provides the core security and governance layer that aligns platform actions with approved operational, compliance, and administrative access rules.

search document templates ​

Search document templates is an MCP Work tool in the Autologyx platform that retrieves the document templates available for a specific Object Class. It is used by developers and integrators when building automations, integrations, or AI-assisted workflows that need to identify which templates can be used for document generation in a given business context. This matters because document templates are tied to object types in the platform, and searching them programmatically allows a solution to select the correct template set before generating or downloading object record documents, helping ensure that downstream document-handling steps use the right template for the target record.

search object classes ​

In the Autologyx platform, search object classes is an MCP Work tool used to find Object Class definitions that match supplied search criteria. It is used by developers, integrators, and configuration administrators when they need to identify the correct Object Class before working with object records, custom Object Class fields, field aliases, or field slugs, and before calling related operations such as get object class, create object record, or create object records hierarchy. This matters because Object Classes define the structure and type of records used in the platform, so being able to search for the right class is a key step in configuring integrations, selecting the correct schema, and ensuring downstream record creation and retrieval actions target the intended data model.

search object record children ​

Search object record children is an MCP Work tool in the Autologyx platform that retrieves the child Object Records linked to a specified parent Object Record. It is used by developers and integrators when working with object hierarchies, especially in workflows, service integrations, or automation that need to inspect or process related records beneath a parent record. This tool matters because it provides a direct way to navigate structured Object Record relationships, supporting solutions that depend on parent-child data models such as hierarchy validation, record creation flows, and downstream actions that operate on child records.

search object record documents ​

Search object record documents is an MCP Work tool in the Autologyx platform that searches the documents linked to an Object Record. It is used by developers and integrators when building automations or service integrations that need to find document content or document entries associated with a specific record before taking further action, such as retrieving a document by URL or UUID or working with documents held against child Object Records. This matters because Object Record documents are often the source files for workflow steps, decisions, and downstream processing, so being able to search them efficiently is a core part of implementing document-aware integrations and record-centric automation in Autologyx.

Security, permissions, and governance ​

  • Mostly relevant to: Configuration admins, Super Admins, Information Security / Compliance / Analytics
  • Closely related concepts: AppliedAI

Security, permissions, and governance in the Autologyx platform is the framework used to define, control, and audit who can access platform capabilities, what actions they can perform, and how those actions are governed across users, agents, instances, clients, matters, and individual records. It is used when configuring access models, setting granular permissions, enforcing guardrails, introducing human-in-the-loop controls, and separating read-only AI guidance from actions that can change live data, particularly for AppliedAI and other controlled automation scenarios. This matters because it gives configuration and super admin teams enterprise-grade control over access, attribution, policy enforcement, and activity oversight, helping ensure that AI-assisted and autonomous operations are secure, governed, and aligned with organisational compliance requirements.

Sequence actors ​

Sequence actors are the executable components added to a Sequence in Autologyx to perform individual workflow steps, such as running automated actions or presenting work for manual completion. Used by configuration administrators and super admins when designing and maintaining Sequences in the Sequencer, an actor defines what happens at a specific point in the workflow and can represent capabilities such as AI-driven processing through actors like Azure OpenAI or work handled through related services such as Autologyx MCP Work. Sequence actors matter because they are the building blocks that control how a Sequence operates in practice, determining which tasks are automated, which require user input, and how processing is orchestrated across a case or business process.

Sequence builder ​

Sequence builder is the design environment in Autologyx Catalyst where users create and configure a Sequence by adding actors to a canvas and arranging them to perform functions in response to triggers. It is used when building automation logic, including dragging actors such as the OpenAI: GPT actor onto the Sequence canvas and configuring how they interact with data and other components. The Sequence builder matters because it is the central workspace for defining how a process runs, making it essential for configuration admins who design automations and for end-users who work with the resulting process behaviour.

Sequence canvas ​

The Sequence canvas is the visual workspace in the Autologyx Sequencer where a Sequence is built and arranged by placing actors onto the workflow and connecting them at the required points in the process. It is used in Edit mode by configuration admins when designing or updating Sequences, including adding actors such as AI actors, Local Variable actors, and human review tasks, and positioning them in relation to triggers and other steps. The Sequence canvas matters because it is the primary surface for defining the structure, order, and flow of automated work in the platform, making it central to configuring how a business process runs from one action to the next.

Sequencer ​

In Autologyx, the Sequencer, also referred to as a Sequence, is the workflow orchestration capability used to design and run controlled business processes by linking actors, triggers, data handling, and decision points on the Sequence canvas. It is used by configuration and technical administrators to define how records, tasks, integrations, and AI-enabled steps progress through a workflow, including sending structured requests through actors such as API Call, OpenAI, Azure OpenAI, or Bedrock, then storing and reusing returned values in later steps through merge fields, local variables, and deterministic Sequence logic. The Sequencer matters because it is the point at which business rules, external services, authentication, and automation are coordinated, allowing organisations to build governed, repeatable processes that keep Autologyx in control of workflow execution while extending the platform through integrations and model-agnostic AI services.

Show 3 more pages

Sequences ​

In Autologyx, a Sequence is the configured workflow definition built in the Sequencer that orchestrates business process steps, invokes actors, and applies deterministic logic to data and events as work progresses. Sequences are used in Catalyst workflow automation to interact with Object Classes and Object Records, route and update work, create downstream actions, and, where required, send structured requests to AI services or other external endpoints through actors such as OpenAI, Azure OpenAI, AWS Bedrock, API Call, or Autologyx MCP Work integrations. For configuration admins, developers, integrators, and Super Admins, Sequences matter because they are the primary mechanism for turning process design into controlled execution: they determine when automation runs, what data is passed between steps, how external services are called, and how responses are stored or used to drive subsequent workflow behaviour under governance and platform control.

Show 4 more pages

service account ​

A service account in the Autologyx platform is a non-human account used to let an agent or automated capability act within Autologyx under a defined identity and permission set. It is used when configuring Autologyx MCP Work and related agent-enabled patterns to determine which records, Object Classes, task templates, documents, and actions the agent can access, create, update, or complete, and it sits alongside user-based identities as an execution context for automated work. Service accounts matter because they provide a controlled way to separate machine-driven activity from individual user accounts, apply least-privilege access, support auditing of tool calls and actions, and enable administrators, integrators, and security teams to approve, review, and remove automated access quickly and safely.

standard OpenAI, Azure OpenAI, or AWS Bedrock actors ​

Standard OpenAI, Azure OpenAI, or AWS Bedrock actors are the built-in Autologyx actor integrations used in Sequences to connect directly to supported AI services from OpenAI, Azure OpenAI, and AWS Bedrock. They are used when configuring Applied AI steps that call externally hosted foundation models through Autologyx’s native provider-specific connectors, rather than through privately hosted models or a generic API-based integration. This distinction matters because it determines how a model endpoint is connected in the platform, which configuration approach administrators and integrators should use, and when a privately hosted model, dedicated AI actor, or API Call actor is required instead of the standard provider actors.

structured Autologyx data ​

Structured Autologyx data is the platform’s native business data held and managed in defined records and workflow state, including the fields, metadata, documents, permissions, user task context, and integration outputs that Autologyx uses to run a process. It is used throughout Sequences, the Sequencer, Object Records, and AI-enabled workflows, especially where a dedicated AI actor or privately hosted model needs to consume platform data alongside deterministic Sequence logic. This matters to configuration admins and developers because structured Autologyx data provides the controlled, consistent inputs and process context needed to automate decisions, route work, invoke external or private models, and combine specialist model outputs with the governed workflow and record management capabilities of the Autologyx platform.

structured outputs ​

Structured outputs are AI model responses returned in a defined data structure so Autologyx can use them directly in Sequence logic and workflow processing rather than treating them as free-form text. In the platform, they are used when integrating services such as AWS Bedrock through AI-related configuration and actor design, especially where a model’s response must be consumed as structured data by the Sequencer. Structured outputs matter because they enable deterministic processing of AI results for actions such as routing work, updating records, and creating tasks, making AI-driven steps reliable, configurable, and usable within standard Autologyx workflow automation.

structured responses ​

Structured responses are model or API outputs returned in a defined data structure, rather than as free-form text, so the Autologyx Sequencer can read, validate, and act on the result consistently. In the Autologyx platform, structured responses are used when integrating privately hosted models and other external services through capabilities such as the API Call actor and generic API integrations, where a Sequence expects specific fields or values to drive deterministic Sequence logic. This matters to developers, integrators, and configuration admins because structured responses make automation reliable: they allow Sequences to branch predictably, support validation of returned data, and simplify downstream processing in workflows that depend on exact, machine-readable outputs.

System Configuration Sequences ​

system of record ​

In the Autologyx platform, the system of record, also described as the operational system of record, is the governed execution and activity context where work is performed, tracked, and controlled as part of live business operations. It is used in scenarios such as Autologyx MCP Work, where an approved agent is permitted to participate directly in that operational environment rather than working outside the platform’s managed workflow context. This matters to developers, integrators, configuration administrators, and compliance-focused teams because participation in the system of record ensures autonomous and co-pilot activities occur within the same controlled workflow framework, supporting consistent execution, oversight, and operational integrity.

System prompt ​

A system prompt is a configuration field available for some provider and model combinations, including certain AWS Bedrock integrations in Autologyx, that sets the model’s high-level instructions before it processes a request. It is used when configuring AI behaviour in the platform to define the model’s role, tone, constraints, and required output format, such as acting as a specific assistant, returning valid JSON, using fixed categories, or applying review rules. System prompts matter because they shape how the model responds within an Autologyx workflow, helping configuration admins and integrators align AI output with business rules, downstream processing requirements, and the capabilities exposed by the selected provider and model.

Task ​

A Task in the Autologyx platform is a workflow work item created within a process to represent an action that must be completed, assigned, reviewed, or progressed by a user, team, or approved agent. Tasks are used throughout live operational work alongside records, documents, notifications, and routing, and can be created or updated manually, automatically by process design, or through enabled MCP Work tools. In practice, Tasks are where operational steps are carried out and managed: they can be found, read, assigned, unassigned, completed, and updated as part of moving work through an existing process. This matters because Tasks provide the controlled execution layer for process work, linking human and agent activity to permissions, structured data, downstream workflow actions, and the platform audit trail.

Task templates ​

Task templates are reusable platform definitions for tasks in Autologyx that provide the configured blueprint used to create work items, including Automatic Tasks and related task actions against Object Records and within Sequences. They are used in workflow design and runtime operations, including AI-assisted and MCP Work capabilities that can search available task templates, retrieve template details, and create new Automatic Tasks from a selected template and Object Record. Task templates matter because they standardise how work is initiated and controlled across the platform, allowing configuration admins and integrators to define consistent task behaviour while ensuring users and approved agents create tasks only from authorised, governed templates.

task tools ​

Task tools, also described as Task tool endpoints, are the Autologyx MCP Work capabilities that let an approved agent interact directly with Tasks in the platform. They are used within the MCP Work service to find, create, read, update, assign, unassign, save, and otherwise manage Tasks, providing the operational interface between an agent and Autologyx work items. This matters to developers and integrators because task tools define how approved automated agents can participate in task handling workflows, including working with Manual Tasks and Automatic Tasks, while ensuring task operations are performed through the platform’s supported task-management endpoints.

tenant configuration ​

Tenant configuration, also described as the customer environment, is the set of tenant-specific settings and enabled capabilities that control how the Autologyx platform behaves for a particular customer instance. It is used by Configuration admins and Super Admins when setting up integrations, authentication, subscriptions, and feature availability, and it directly affects what options users can access in areas such as generic API actors and OpenAI-powered actors and configuration modals. Tenant configuration matters because it determines which models, settings, and integrations are available in a workflow, so these platform-level settings must be confirmed in the customer environment before configuring, publishing, or deploying solutions.

Test Azure OpenAI ​

Test Azure OpenAI is the validation action in the Azure OpenAI configuration modal that lets configuration admins and developers run the configured prompt and context against Azure OpenAI before saving the actor. It is used when setting up an Azure OpenAI actor in the Sequencer, especially where the prompt or context contains merge fields, in which case a Record ID must be provided so the test can resolve values from the relevant Object Record. This matters because it allows users to verify that the request is constructed correctly with representative record data before the actor is used in a live workflow, helping ensure the sequence behaves as intended.

Test embeddings ​

Test embeddings is a validation action in the Autologyx OpenAI embeddings configuration flow that lets configuration admins verify an embeddings setup before saving it. It is used in the OpenAI embeddings configuration modal, alongside other actor configuration settings, to confirm that the configured provider details are accepted and the embeddings actor is ready to use in the platform. This matters because it helps admins catch configuration issues during setup, ensuring the actor can be saved with working settings and reducing errors when embeddings are used in downstream Autologyx processes.

Test Integration ​

Test Integration is the action in an actor’s configuration that runs a test request using the current settings so you can validate the integration before saving or using it in a live workflow. It is used in the actor configuration modal for AI and Sequencer integrations such as OpenAI and AWS Bedrock, and when the prompt, message, or context includes merge fields, you enter a Record ID so Autologyx can resolve record data during the test. Running Test Integration confirms that the actor configuration can populate the input correctly, call the selected model or service, and return a usable response, making it an essential step for configuration admins and integrators when verifying setup, record-data mapping, and expected behaviour.

The Sequencer ​

INSUFFICIENT_EVIDENCE

tool permissions ​

Tool permissions in Autologyx control which MCP Work tools an agent is allowed to use. They are used within the Applied AI and MCP Work configuration context to grant access to specific tools rather than exposing every available tool to every agent. This matters because tool permissions determine the functional scope of an agent, helping developers, configuration admins, and Super Admins ensure that each agent can perform only the actions it has been explicitly authorised to perform.

transaction ID ​

In the Autologyx platform, a transaction ID is the unique identifier returned when an MCP Work tool starts a long-running operation, such as creating an object records hierarchy or checking object records hierarchy creation. It is used by developers and integrators as the required input to subsequent MCP Work status tools so the platform can retrieve and track the specific operation that was initiated. This matters because the transaction ID links the start request to its follow-up status calls, enabling correct monitoring of processing until the transaction reaches a completed or failed state.

trigger ​

In the Autologyx platform, a trigger is the connection in a Sequence that causes one actor or object-class event to start the next step in the workflow. Triggers are used in the Autologyx Catalyst Sequence builder to link components on the canvas, such as connecting an Email Intake Object Class to an OpenAI: GPT actor or chaining one actor to another. For configuration admins and developers, triggers matter because they define the execution flow of an automation: they determine when an actor runs, how processing moves through the Sequence, and how each configured step is coordinated to deliver the intended workflow outcome.

Unrestricted, Public ​

Unrestricted, Public is an Autologyx classification label that identifies documentation or platform content as approved for open sharing, with no internal handling restrictions. In the Autologyx platform and its documentation set, this classification is shown on pages such as Applied AI, public AI provider guidance, API call examples, and MCP service content to indicate that the material is suitable for general distribution and does not require controlled access. This matters to configuration admins, Super Admins, and compliance stakeholders because it provides a clear governance signal for how information can be used, shared, and referenced when configuring integrations, reviewing platform guidance, or publishing customer-facing material.

user context ​

In the Autologyx platform, user context is the identity and permission scope under which an action, service, or approved agent operates, determining what platform resources and data it can access when work is performed. It is used in applied AI and MCP Work configurations as a control mechanism alongside exposed tools, the account used by the agent, and the platform’s role-based access model. User context matters because it defines the effective access boundary for controlled autonomous workflows, helping configuration admins, super admins, developers, and compliance stakeholders ensure that automated actions run with the correct level of authority, align with security policies, and are constrained to the intended operational scope.

user groups ​

User groups are collections of Autologyx users used to manage access, task assignment, and operational control at scale. In the platform, user groups are configured alongside user accounts, permissions, MCP mappings, and governance gateway controls to determine what an MCP enabled agent can see and do, and they can also be used when assigning work to a group rather than an individual user. This matters because user groups provide a structured way to apply consistent access rules, support auditability, and align agent and user activity with organisational governance, security, and compliance requirements.

variable ​

A variable, including a JSON variable, is a named value created in an Autologyx sequence to store data so it can be reused by later actors and configuration steps. Variables are typically set with the Local Variable actor, where you define the variable name, choose its type, identify the source data, and map the value to be stored; for JSON variables, the stored value must be valid JSON. In practice, variables are used to capture outputs from actors such as the OpenAI: GPT actor and make that data available throughout the Sequencer, including for downstream processing and field selection. Variables matter because they provide a structured way to persist and pass data between actors, enabling dynamic, multi-step automations to use generated or extracted content reliably.

write actions ​

Write actions are Autologyx tools and operations that change platform data or relationships rather than simply reading information. In the Autologyx platform, this term is used in MCP Work tool documentation to identify actions such as creating, updating, assigning, unassigning, saving, generating, downloading, and removing relationships, including related operations such as creating object records, creating record hierarchies, changing task assignments, generating documents, and downloading record documents. This classification matters because write actions actively modify records, tasks, documents, or links between records, so developers, integrators, configuration administrators, and governance teams use it to understand which tools perform state-changing operations, what required inputs must be provided, and which actions require stronger control, review, and audit attention during configuration and use.

write tools ​

Write tools, also described as write actions, are MCP-enabled capabilities in the Autologyx platform that let an agent or workflow make changes in connected systems rather than only read data. They are used when configuring MCP services, defining tool access for MCP-enabled agents, and reviewing the MCP tool catalogue and Available MCP Work tools, especially for actions such as creating tasks, updating records, generating documents, and performing bulk actions. Write tools matter because they directly affect operational data and outcomes, so configuration admins, super admins, security and compliance teams, and developers must enable them deliberately, validate connection and permission settings, and ensure appropriate audit logging, governance, and monitoring controls are in place before they are used in co-pilot or autonomous patterns.

assignment rules ​

INSUFFICIENT_EVIDENCE

cut list ​

In Autologyx, a cut list, also called an implementation cut list, is a structured breakdown of the configuration and implementation items that need to be created, updated, or reviewed to deliver a solution from captured requirements. It is used in MCP Customer Success and related implementation planning workflows to turn unstructured client inputs into actionable build work, such as Object Classes, fields, parent and child relationships, form sections, task templates, Sequence logic, document templates, merge fields, integrations, authentication requirements, reporting fields, migration mappings, test scenarios, and client clarification points. A cut list matters because it gives configuration admins, Super Admins, and developers or integrators a clear, organized view of the platform changes required, and it can be grouped by phase, priority, dependency, or workstream to support solution design, delivery planning, and implementation control.

form sections ​

Form sections are the structural groupings used to organise fields within an Autologyx form, defining how information is laid out and presented to users on records and task-driven interfaces such as Manual Tasks. Configuration admins use form sections when designing or updating object class forms and related record views, alongside field placement decisions, to ensure the right data is captured in a clear and usable layout. Form sections matter because they directly affect form usability, data entry efficiency, and the consistency of information shown across the platform, and they are often planned as part of implementation cut lists together with fields, document templates, and merge field requirements.

parent and child record relationships ​

In the Autologyx platform, parent and child record relationships define how one record is linked to one or more subordinate records in the data model, establishing a structured hierarchy between Object Classes. These relationships are used during solution design and platform configuration to model connected business entities, organise related work and information, and support how records are created, viewed, and managed across a process. They are commonly identified alongside Object Classes, fields, task templates, and form design when producing a cut list or implementation plan, including through Autologyx MCP Customer Success. For configuration admins and developers, these relationships matter because they shape the platform’s core record structure and directly influence usability, maintainability, and the overall fit of the configured solution to the client’s operational model.

record lifecycle ​

In the Autologyx platform, record lifecycle is the defined progression of an object record through its managed states from creation and ownership through updates, use in workflow, and eventual completion, closure, or retirement. It is used when designing and reviewing the platform data model, alongside object classes, fields, relationships, and ownership, and it also influences workflow triggers, task creation, reporting, governance, and migration planning. Record lifecycle matters because it determines how records are controlled over time, what actions and automations are allowed at each stage, how access and accountability are maintained, and how the platform supports operational, compliance, and analytics requirements.