Agent's behaviour

The main benefit of cognition is that you can easily configure how the GenAI agent behaves in order to answer a question or solve tasks for you. The editor screen is only available to the role of an engineer. One of the advantages of this editor is the ‘Show route’ which is functionality that shows step by step how the query was executed. The idea behind the ‘Show route’ is to use it as a debugger, so possible errors can be easily found, understood and corrected.

When you open the editor, you will see an editor like this:

Every project is composed of one or more strategies, each of which contains one or more nodes. You can think of a strategy as a toolset, with each tool having different capabilities. For example, one strategy might be used to answer questions based on documents ran through ETL (Data Processing Documentation Section), another to make API calls to the web, and a third to upload and process documents. The strategies can be edited, deleted, imported, exported and the nodes of the strategies can be drag and dropped.

The abilities of the agent are determined by these nodes, and there are numerous ways to customize and enhance both the nodes and strategies to meet your specific needs. Each node processes the input—a message—and produces an output. For instance, given a question, you can trace the path the message takes through the pipeline.

The data that is processed is always two-fold:

a 'record_dict' a dictionary that stores the current state of the message and its metadata
a 'scope_dict' a dictionary you can use that remembers the state of the conversation across messages

If you look into the output of the first node, you will see the initial state of the record_dict. Also, for every step, you can see in a Git-diff-like editor what changes have been made by the node.

The Smart Router

One of the most powerful features of a project is the smart router, which can dynamically select the appropriate strategies based on user inputs.

However, you don't always need to use the "smart" component of the smart router. The routing logic can also be programmed to be static if desired.

Example:

Suppose you want to check your user's intent before deciding the next steps. You can hardcode a condition to always route to a specific strategy for intent checking before proceeding further:

In this strategy, you can then add "intent" as a key to the record_dict to ensure this strategy is no longer triggered. Based on the intent, you can decide the next course of action. For example, if the user's intent is to retrieve data from a database, you can route to a strategy designed for database queries. Alternatively, if the user simply wants a summary, you can route to a generic language model.

If no static routing is programmed, the smart router will automatically take over and decide the strategy to use based on the description of a strategy. The description can be seen as an instruction prompt on when to use a strategy.

In addition to the description, the input and output parameters of a strategy are crucial. The input parameters act as conditions that enable or disable the use of strategies. The output fields specify which keys from the record_dict and scope_dict should be retained after the strategy has executed. These keys are added during the steps of the current strategy.

Key-value pairs from both dictionaries that were present before entering a strategy will always be preserved, without the need to specify them again. For example, if you generate an answer from a language model and save it under the key "answer," you must set rd.answer as one of the output fields; otherwise, it will be discarded at the end. This approach allows for more granular control over inputs and outputs, preventing temporary data from being unnecessarily saved or overwritten.

The abbreviation "rd" stands for record_dict, while "sd" stands for scope_dict.

The strategies consist of as many sequential nodes as you want. Currently, there are the following nodes available:

Python: Allows you to add custom Python code, which can be useful for data transformation or custom API calls. Many important libraries are also already installed.
Answer LLM: Allows you to use an LLM to generate a final answer for RAG use cases.
Selection: Sets a filter selection widget to the UI of the chat intergace.
Transformation LLM: Allows to use a LLM for data transformation or classification tasks.
Trucate Context: Shortens the contexts in cases that LLMs with smaller context windows are used.
Header: his node updates the header of the conversation based on the first question and answer pair.
Tmp Doc Retrieval: Needs to be added allow the processing of PDF documents that the user can upload. Needs to be enabled in the general project settings.
Call other Agent: Let’s you call an agent from another project. Allows for multi-agent projects.
Neural Search: Neural Serach of chunked, embedded documents. Useful for RAG-related tasks.
Webhook: Integration of a webhook into a strategy.

A typical node can be e.g. a selection widget node, which asks the user which documents to filter for (in case you only want to look into a subset of the knowledge base to answer a question). These kind of nodes can be used to dynamically configure the behaviour of the GenAI agent.

Also, you can use low-code Python nodes to implement any kind of GenAI agent behaviour. The Python node always takes as input the record_dict, scope_dict, and then returns a tuple. The first value of the tuple is the new record_dict, the second is the new scope_dict.

Last but not least, you usually want to use a LLM node to generate an answer to the question. You can select from a range of LLMs via the no-code editor, where you can implement prompt templates. We're using mustache.js under the hood to allow dynamic variable inputs.

You can always render what the LLM will actually see for a given message.

If you want, you can change the sequential action steps of a strategy. This can be done via the arrows or via drag and drop.

Also, you can click on the "API" button to see the API specifications and to see the current state of the scope_dict.

You can see the current conversation by clicking on the "Show" button at the top right corner.

In here, you can also see the logs of the specific actions taken to create the actual answer, enabling full transparency.

Each agent can be accessed via API, either via REST or Websocket. For this, copy the code from the API section and generate a personal access token.