Robility flow data types

Data

Data ports  accept or produce the Data type, which is a structured data object, like a JSON payload that you might send to an API. This data type is used to pass key-value pairs between components, such as user profiles, settings, or other structured information.

Data objects include a primary text field, indicated by a text_key, and additional metadata.

Schema and attributes

The schema is defined in data.py.

The following attributes are available:

a. data: A Data object stores key-value pairs within the .data attribute. This is the Data object’s core dictionary. Each key is a field name, and the values can be any supported data type.
b. text_key: The key in data that is considered the primary text value.
c. default_value: Fallback if text_key is missing. The default text_key is “text”.

data_obj = Data(

    text_key=”text”,

    data={

        “text”: “Hello world”,

        “name”: “Charlie”,

        “age”: 28

    },

    default_value=””

)

Data objects can be serialized to JSON, created from JSON, or created from other dictionary data. However, the resulting Data object is a structured object with validation and methods, not a plain dictionary. For example, when serialized into JSON, the previous Python example becomes the following JSON object:

{

  “text_key”: “text”,

  “data”: {

    “text”: “Hello world”,

    “name”: “Charlie”,

    “age”: 28

  },

  “default_value”: “”

}

DataFrame

DataFrame ports accept or produce pandas DataFrames, which are similar to the tabular CSV data. Use the DataFrame type to work with data containing multiple rows or records.

Schema and attributes

The schema is defined in dataframe.py.

The following attributes are available:

1. Full pandas compatibility: All pandas DataFrame methods and functionality are supported
2. Robility flow integration: Accepts lists of Data objects, dictionaries, or existing DataFrames. 
3. Convenience methods:

a. to_data_list()
b. add_row()
c. add_rows()
d. to_lc_documents()
e. to_data()
f. to_message()

4. Text key support: Maintains text_key and default_value attributes for Data object compatibility.

DataFrame structure

A DataFrame has a tabular data structure with rows and columns. Keys are columns, and each object in the array is a row.

[

  {

    “name”: “Charlie Lastname”,

    “age”: 28,

    “email”: “charlie.lastname@example.com”

  },

  {

    “name”: “Alexandra Example”,

    “age”: 34,

    “email”: “alexandra@example.com”

  }

]

When represented as tabular data, the preceding DataFrame object is structured as follows:

| name | age | email |

|——|—–|——-|

| Charlie Lastname | 28 | charlie.lastname@example.com |

| Alexandra Example | 34 | alexandra@example.com |

Embeddings

Embeddings ports  emit or ingest vector embeddings to support functions like similarity search.

The Embeddings data type is used specifically by components that either produce or consume vector embeddings, such as the Embedding Model components and Vector Store components.

For example, Embedding Model components output Embeddings data that you can connect to an Embedding input port on a Vector Store component.

LanguageModel

The LanguageModel type is a specific data type that can be produced by Language Model components and accepted by components that use an LLM.

When you change a Language Model component’s output type from Model Response to Language Model, the component’s output port changes from a Message port to a Language Model port .

Then, you connect the outgoing Language Model port to a Language Model input port on a compatible component, such as a Smart Function component.

For more information about using these components in flows and toggling LanguageModel output, see Language Model components.

Memory

Memory ports are used to integrate a Message History component with external chat memory storage. For more information, see the Message History component.

Message

Message ports  accept or produce Message data, which extends the Data type with additional fields and methods for text input typically used in chat flows.

This data type is used by many components.

Points to note:

Components that accept or produce Message data may not include all attributes in the incoming or outgoing Message data. If the data is compatible with the Message schema, it can be valid.

When building flows, focus on the fields shown on each component in the workspace, rather than the data types passed between components. The details of a particular data type are often only relevant when you are debugging a flow or component that isn’t producing the expected output.

For example, a Chat Input component only requires the content of the Input Text (input_value) field. The component then constructs a complete Message object before passing the data to other components in the flow.

Schema, structure, and attributes

The Message schema is defined in message.py. Some Message attributes have their own schema definitions, such as content_block.py.

Message data is structured as a JSON object. For example:

{

  “text”: “Name: Charlie Lastname, Age: 28, Email: charlie.lastname@example.com”,

  “sender”: “User”,

  “sender_name”: “Charlie Lastname”,

  “session_id”: “some-session-id”,

  “timestamp”: “2024-06-01T12:00:00Z”,

  “files”: [],

  “content_blocks”: [],

  “category”: “message”

}

The attributes included in a specific Message object depend on the context, including the component type, flow activity, and whether the message is a query or response. Some common attributes include the following:

a. text: The main message content.
b. sender: Identifies the originator of a chat message as either User or Language Model.
c. sender_name: The display name for the sender. Defaults to User or Language Model.
d. session_id: The chat session identifier.
e. flow_id: The ID of the flow that the message is associated with. flow_id and session_id are the same if the flow doesn’t use custom session IDs.
f. timestamp: The UTC timestamp that the message was sent.
g. files: A list of file paths or images included with the message
h. content_blocks: Container for rich content input, such as text, media, or code. Also contains error message information if the LLM can’t process the input.
i. category: “message”, “error”, “warning”, or “info”.

Not all attributes are required, and some components accept message-compatible input, such as raw text input. The strictness depends on the component.

Message data in Input and Output components

In flows with Chat Input and Output components, Message data provides a consistent structure for chat interactions, and it is ideal for chatbots, conversational analysis, and other use cases based on a dialogue with an LLM or agent. In these flows, the Playground chat interface prints only the Message attributes that are relevant to the conversation, such as text, files, and error messages from content_blocks. To see all Message attributes, inspect the message logs in the Playground.

In flows with Text Input and Output components, Message data is used to pass simple text strings without the chat-related metadata. These components handle Message data as independent text strings, not as part of an ongoing conversation. For this reason, a flow with only Text Input and Output components isn’t compatible with the Playground. For more information, see Input and Output components.

When using the Robility flow  API, the response includes the Message object along with other response data from the flow run. Robility flow  API responses can be extremely verbose, so your applications must include code to extract relevant data from the response to return to the user. For example, see the Robility flow QuickStart.

Additionally, input sent to the input port of input/output components does not need to be a complete Message object because the component constructs the Message object that is then passed to other components in the flow or returned as flow output. In fact, some components shouldn’t receive a complete Message object because some attributes, like timestamp should be added by the component for accuracy.

Tool

Tool ports connect tools to an Agent component.

Tools can be other components where you enabled Tool Mode, they can be the dedicated MCP Tools component, or they can be other components that only support Tool Mode. Multiple tools can be connected to the same Agent component at the same port.

For more information, see Configure tools for agents and Use Robility flow as an MCP client.

Unknown or multiple types

If a port can accept or produce multiple data types, it is represented by the gray port icon.

Hover over the port to see the accepted or produced data types.

View data types in flows

In Robility flow , you can use  Inspect output to view the output of individual components. This can help you learn about the different data types and debug problems with invalid or malformed inputs and output.

The following example shows how to inspect the output of a Type Convert component, which can convert data from one type to another:

1. Create a flow and then connect a Chat Input component to a Type Convert component. 
2. In the Chat Input component, enter some text for the type converter to process. 
3. On the Type Convert component, click Run component, and then click Inspect output.

The default output is Message data, which is the same as the input coming from the Chat Input component. To see the Message data converted to Data or DataFrame, change the Output Type on the Type Convert component, and then rerun the component.

a. Message
b. Data
c. DataFrame