Agents

An Agent is an automated workflow that performs specific tasks based on predefined logic, actions, and conditions. It helps users complete processes without manual intervention by guiding steps, collecting information, making decisions, and triggering actions automatically.

In simple terms, an agent works like a smart assistant inside the system that can interact with users, process inputs, validate conditions, call external services, and navigate workflows based on the configured steps.

For example, an agent can:

• Answer user queries
• Validate information
• Trigger API calls
• Capture page details
• Route users to different paths based on conditions
• Interact with Knowly for guidance
• Handle document-based processes

Agent Actions

Agent Actions are the individual steps used to build an agent workflow and define how the agent performs tasks. Each action is designed for a specific purpose, such as collecting user input, calling APIs, making decisions, capturing data, or guiding users through processes. These actions work together to automate business flows and reduce manual effort. By arranging different actions in sequence, users can create smart and dynamic workflows based on business requirements. Agent Actions help ensure the agent responds accurately and follows the correct process from start to finish.

Available Agent Actions

Prompt

Prompt is used to interact with users by asking questions, collecting input, or displaying important messages during the workflow. It helps guide users through the process by requesting required information at the right step. This action is useful for validations, confirmations, and user responses. It ensures the workflow continues based on the provided input.

Prompt Settings

• Node Title : A node title is a clear and descriptive name assigned to a node that identifies its role or purpose within a workflow.
• Instruction: The instruction defines what the agent should do with the provided input and how results should be returned.It controls the agent’s processing behavior within the flow.
• Output Type: Output Type defines the response format expected from the prompt. It can be either Text or **JSON ** depending on the workflow requirement.
• Inject Source Prompt: Inject Source Prompt can be enabled or disabled. When enabled, it retrieves data from the input field and uses it in the prompt response. When disabled, it does not use the input field data.

Document

Document is used to manage document-related tasks within the workflow, such as referencing, or validating files. It helps handle business processes that require document verification or information extraction. This action ensures documents are properly linked to the workflow. It is commonly used in approval and compliance processes.

• Node Title : A node title is a clear and descriptive name assigned to a node that identifies its role or purpose within a workflow.
• Upload Document: The Upload Document section allows users to add files into the system. These documents are then made available for reading, extraction, or processing within the flow.
• Instruction: The instruction defines what the agent should do with the provided input and how results should be returned.It controls the agent’s processing behavior within the flow.
• Output Type: Output Type defines the response format expected from the prompt. It can be either Text or **JSON ** depending on the workflow requirement.
• Inject Source Prompt: Inject Source Prompt can be enabled or disabled. When enabled, it retrieves data from the input field and uses it in the prompt response. When disabled, it does not use the input field data.

Web Service Call

Web Service Call is used to connect the agent with external systems or backend APIs to send or retrieve data. It allows the workflow to interact with real-time business information from other applications. This action helps automate tasks like checking order status or fetching customer details. It improves integration and reduces manual work.

• Node Title : A node title is a clear and descriptive name assigned to a node that identifies its role or purpose within a workflow.
• Endpoint: The Endpoint field specifies the exact URL of the web service or API that will be called. It acts as the target address where the request is sent. This is required for identifying which backend service should process the request.
• Http Method: The HTTP method defines the type of operation to be performed on the endpoint. It determines whether data will be fetched, created, updated, or deleted.

1. Get: GET is used to retrieve data from a server or API.
2. Post: POST is used to send new data to the server. It is commonly used for creating new records or submitting information.
3. Put: PUT is used to update existing data on the server. It replaces or modifies the complete existing resource with the new data provided.
4. Delete: DELETE is used to remove existing data from the server. It permanently deletes the specified resource identified in the request. Once executed successfully, the data is no longer available.

• Payload: The Payload field contains the data sent in the body of the request. It is mainly used in POST and PUT requests where information needs to be submitted to the server. This data is structured in formats like JSON or form data.
• Headers: Headers in a WebService API are additional pieces of information sent along with the API request and response. They help define how the request should be processed, what type of data is being sent, and how the server should respond. Headers act as instructions between the client and the server, ensuring proper communication and successful data exchange.

1. Content-Type → application/json

This header specifies the format of the data being sent in the request body. When set to application/json, it tells the server that the request payload is structured in JSON format. This is commonly used when sending data such as user details, form submissions, or transaction information.

2. Accept → /

This header defines the type of response the client is willing to receive from the server. When set to /, it means the client can accept any response format, such as JSON, XML, text, or others.

3. Cache-Control → no-cache

This header controls how caching should be handled. When set to no-cache, it ensures that the request fetches fresh data from the server instead of using previously stored or cached responses.

4. User-Agent → WebServiceActionClient

This header identifies the application, system, or client making the API request. It helps the server recognize the source of the request for logging, monitoring, debugging, or security purposes.

5. Accept-Encoding → gzip, deflate, br

This header tells the server which compression formats the client supports for the response. Compression helps reduce response size, improve performance, and speed up data transfer.

gzip → Common compression format

deflate → Another compression method

br → Brotli compression (more efficient in many cases)

• Params: Params are key-value pairs used to pass additional data with the request, usually for filtering or customizing results. They are often appended to the URL as query parameters. Each parameter has a defined key and its corresponding value.

1. Params Key: The params key is the name of a parameter that defines what kind of data you want to send or filter in the API request. It acts as an identifier for the value you are passing.
2. Params Value: The params value is the actual data assigned to the key. It provides the specific input the server uses to process or filter the request based on the given key.

• Authentication Type: Authentication type defines how the request is secured and verified before access is granted. It ensures that only authorized users or systems can interact with the API.

1. No Auth: No Auth means the API does not require any authentication to access it. Anyone can send a request and receive a response without providing credentials like username, password.
2. Basic: Basic Authentication is a simple security method used to verify the identity of a user or system when calling an API. It requires a username and password, which are encoded and sent with each request in the header.

📘

Username And Password: The server checks these credentials to confirm access before processing the request. If the credentials are correct, the request is allowed; otherwise, it is rejected. It is commonly used for simple or internal APIs but is less secure compared to token-based authentication.

3. Bearer Token: Bearer Token is a secure authentication method where access is granted using a token instead of username and password. The token is generated by an authentication system and is included in the request header to verify access. This token is a unique string issued to the user or system after successful login or authorization. It is sent with every API request to prove identity and access rights without repeatedly sending credentials.

Teams Activity

Teams Activity is used for sending notifications or updating communication activities to the Microsoft Teams. It helps keep users informed during workflow execution. This action supports collaboration by connecting workflow events with Teams interactions. It is useful for alerts, reminders, and status updates.

Branching

Branching is used to create decision-based paths in the workflow depending on conditions or user responses. It helps the agent decide which step to follow next based on specific logic. This action makes workflows dynamic and flexible instead of following a single fixed path. It improves process accuracy by handling different scenarios automatically.

• Node Title : A node title is a clear and descriptive name assigned to a node that identifies its role or purpose within a workflow.
• Branch Name: Branch Name is used to name a specific branch in branching logic. t helps distinguish different branches in a clear and organized way.
• Branch Rule: Branch Rule specifies the logic that determines when a branch is executed. If the defined condition matches the output, the workflow proceeds through that branch.
• Default Branch: The Default Branch is the fallback path in the workflow. If no conditions are satisfied, the flow automatically proceeds through this branch.

Knowly Interaction

Knowly Interaction is used to create meaningful communication between the agent and the user throughout the workflow. It helps the system guide users, provide relevant information, and handle interactions in a clear and efficient way. This action improves the overall user experience by making the process more interactive and responsive. It ensures the workflow progresses smoothly while keeping the user informed at each step.

• Node Title : A node title is a clear and descriptive name assigned to a node that identifies its role or purpose within a workflow.
• Answer: The Answer type is used when we provide a direct response to the user’s query. It can also be used to display the previous output or already generated information. This interaction focuses on delivering information clearly without requiring additional input from the user.
• Use Previous Output: This answer uses the output from a previous step.
• Message: In this field, the text you enter will be displayed directly to the user as the response.
• Ask Follow Up: This type is used when additional information is needed from the user. In this interaction, we write a question to collect more details, clarify the request, or continue the conversation flow before proceeding to the next step.
• Question: This field is used to enter the question that will be displayed to the user for further input or details.
• Confirmation Request: The Confirmation Request type is used when user confirmation is required before moving forward. In this interaction, we provide a prompt based on the action or decision, and two buttons are displayed for the user: Confirm and Cancel. This is used to ask the user for final confirmation before continuing with an action or decision, using Confirm and Cancel buttons.
• Prompt: This field contains the message that asks the user to confirm or cancel the requested action.
• Confirm: The Confirm button is used when the user agrees to proceed with the action or approves the request.
• Cancel: The Cancel button is used when the user wants to stop the process or does not approve the requested action.

HTML Capture

HTML Capture is used to capture specific page elements, values, or content directly from the application interface. It helps extract UI information for validation, tracking, or automation purposes. This action is useful when the workflow needs to read data from the screen dynamically. It improves accuracy by using real-time page information.

• Node Title : A node title is a clear and descriptive name assigned to a node that identifies its role or purpose within a workflow.
• Instruction: This field is used to define instructions for the agent about what should be captured. You can guide the system to extract specific content such as form data, inner text, or full HTML structure. It helps clarify the purpose of extraction, such as retrieving visible text, structured data, or converting content into HTML format.
• CSS Selector: This field is used to define the target HTML element using a valid CSS selector. It supports selectors like class names, IDs, or combinations that uniquely identify an element on the page. A correct selector ensures accurate data extraction.
• Output Type:This option defines the format of the extracted data. You can choose between Text, or JSON depending on how you want the output to be structured. The selected format determines how the captured content will be stored and used later in the flow.

1. Text: Output is written in natural human-readable language for users, without any structured format, keys, or brackets, and presented as plain sentences or descriptions.
2. JSON: Output is structured for machine processing, designed for system use, and represented using key-value pairs.

• Enable Fallback: This toggle provides an alternative extraction method when the primary selector fails. If enabled and the element is not found or returns empty, the system will capture the full page content instead to avoid data loss.
• Use raw HTML: This option controls whether the system captures raw HTML or processed content. When enabled, it returns the complete unprocessed HTML of the selected element. When disabled, it returns cleaned or formatted content instead.

Dynamic Data Referencing in Agent Workflow

In the Agent workflow, dynamic data referencing allows values from previous steps or initial inputs to be reused across different actions. These references can be used in any configurable field within the agent (e.g., payload, headers, message body, prompts, URLs, or documents).

The agent executes multiple actions such as knowly interaction, prompt, document processing, loop, and webservices. Each action generates output data that can be reused in subsequent steps.

To enable this, we use dynamic variables to reference:

• Initial input data
• Outputs from previous steps

This ensures seamless data flow across the entire workflow without hardcoding values.

How Data is Accessed

1. $.input
   • Refers to the initial data provided at the start of the agent execution.
   • Can be used in any field where input data is required.
   • The syntax used to access data from the initial input data in the agent workflow is {$.input}.

Example Use Cases:

• Displaying user input in interaction responses
• Sending input data in API requests
• Using input values inside prompts

2. $.steps.stepId
   • Refers to the output of a specific step using its Step ID.
   • Enables accessing processed or transformed data from earlier steps.
   • The syntax used to access data from previous steps in the agent workflow is {$.steps.stepId}.

Example Use Cases:

• Using prompt output in a webservice request
• Passing document data into another step
• Displaying processed results in interaction responses
• Using loop results in notifications

Scenarios

The user is on the correct deal creation page and checks if a valid deal has been successfully detected. Once the deal is identified, the agent extracts the relevant deal information and displays it in Knowly in a clean, user-friendly format instead of raw JSON. The agent then asks the user whether the deal should be registered. If the user confirms, the deal information is automatically posted to Microsoft Teams, completing the registration workflow successfully.

Agent Workflow Example

1. The first action is a Knowly interaction using the Confirmation Request type. It is used to verify that the user is on the correct page and to confirm them to proceed with filling in the required form data.

2. In the second action, the HTML Capture is used with a prompt to extract information from the form element. The extracted data is then formatted and presented in a user-friendly Markdown structure for better readability and clarity.

3. In the third action we are using the knowly interaction where we take the output from the previous action and present it as the answer.

3. The fourth action is a Knowly interaction using the Confirmation Request type. It is used to verify that the user successfully registered the deal.

4. In the fifth action, branching is used to handle the user’s response from the confirmation message. If the user selects “Yes,” a message is displayed on the team indicating successful confirmation. If the user selects “No,” the system responds that the deal has not been registered.

6. In this action, Team Activity is used to send updates based on the user’s confirmation. When the response is “Yes,” the result from Step 2 is shared with the team along with a message confirming that the deal has been successfully registered.

7. In this action, a Knowly Interaction Answer is used to handle the negative confirmation. If the user selects “No,” a message is displayed indicating that the deal has not been registered.

Once all actions are configured, connect the complete agent flow by linking each step in sequence. Then, use the debug mode to execute and test the agent’s workflow.

Output of the Agent Workflow Example

Complete Workflow Overview

Agent Logging:

This feature enables portal users to view agent execution history and inspect execution details when available. It provides a structured UI for monitoring agent activity and supports troubleshooting by exposing detailed execution data in a controlled and user-friendly manner.

The Agent Execution Logs module displays a list of execution records associated with a specific agent. Each record includes essential metadata such as execution start time, duration, and the triggering application.

Extended Agent Logs Setting

Within the Manage Tenant → Agent Settings, an option “Enable Extended Agent Logs” is available to control the level of execution logging.

When Enabled:

• Agent execution logs are captured at an extended level.
• The “View Execution Details” action becomes available input and output data of the agent is displayed.
• Users can access structured and formatted execution stack Readable representation of extended execution data and detailed information is displayed in a modal/dialog for better clarity and troubleshooting.

When Disabled:

• Only basic execution metadata is available in the logs table.
• Extended execution data is not captured or displayed.
• The “View Execution Details” action is hidden.

To access agent logs, go to the Agent tab in the portal and identify the specific agent whose execution history you want to review. Open the context menu (three-dot menu) for that agent, and from the list of available options, select Logs to proceed to the execution logs view.

After selecting the Logs option, the execution logs page is displayed, providing a comprehensive view of all log entries related to the selected agent. This section allows users to review key execution details, including start time, duration, and the triggering application.

Within the logs interface, an Extended Logging option is available to access more detailed execution information. When selected, it opens a comprehensive view of the agent execution logs, including a structured and well-formatted execution stack.