Creating and Configuring AI Agents

An AI Agent's Settings define the provider it uses, the instructions that guide its behavior, its model options, Knowledge Sources, Prompt Library, and usage-management controls.

Configure the Agent around a specific responsibility. A focused Agent with clear instructions and carefully selected tools is easier to test, secure, and maintain than an Agent expected to handle unrelated tasks.

Before You Begin

Every Agent requires an AI provider Connection.

OpenAI is currently the supported AI provider. ioLoop's Agent configuration uses the general concept of an AI provider Connection so that additional providers can be supported in the future.

Before creating the Agent:

1. Open Integrations.
2. Create an OpenAI Connection and configure its profile.
3. Test the Connection.
4. Identify the Agent's intended users and responsibilities.
5. Identify the Project data, files, functions, and external tools it actually needs.

Do not put provider credentials in instructions, model parameters, Knowledge Source descriptions, or Cloud Flow code. The Connection profile manages those credentials.

Create the Agent

To create an Agent:

1. Open AI Agents in the Project Editor.
2. Select New AI Agent.
3. Enter a meaningful name.
4. Save the Agent.
5. Open its actions and select Settings.
6. Expand AI Provider Connection.
7. Select the provider Connection.
8. Select Connect and wait for initialization to finish.

The Agent must be initialized before you can add Knowledge Sources or use its other runtime-dependent settings.

Choose a stable name that reflects the Agent's responsibility, such as SupportAssistant, ProductAdvisor, or RegistrationReviewer. Names can be referenced by Widgets, Cloud Flow, and other Project configuration.

Settings Areas

The Settings panel is organized into these areas:

Area	Purpose
AI Provider Connection	Selects and initializes the provider used by the Agent.
Model Parameters	Defines instructions and supported model behavior.
Prompt Re-inforcement	Adds per-turn reminders before and after each user prompt.
Knowledge Sources	Configures files, tables, functions, web search, MCP servers, and supported Connections.
Prompt Library	Provides reusable categorized prompts.
Manage Usage	Shows usage and manages history, logs, and generated files.

Knowledge Sources and usage management are covered in their dedicated guides.

AI Provider Connection

The selected Connection determines the provider profile and credentials used for model requests.

Changing the provider Connection can affect:

• Available models and model parameters.
• File, search, code-execution, structured-output, and tool capabilities.
• Usage and billing at the provider.
• Data-processing and retention behavior.
• Existing Knowledge Sources that depend on provider-side resources.

Test the Agent after changing its Connection. Do not assume that provider-specific model settings will have the same meaning when additional providers become available.

The Connection is distinct from Connection Knowledge Sources. The AI provider Connection runs the Agent's model; a Connection Knowledge Source gives that model access to functions exposed by another supported Connection.

Model Parameters

The Model Parameters section contains the Agent's primary behavior settings.

Setting	Purpose
AI Model Parameters	Optional advanced JSON configuration passed to the selected provider.
System Instructions for the AI Model	Defines the Agent's role, boundaries, priorities, and expected behavior.
Allow Running Code	Allows supported model code execution, including generation of charts, images, and files such as CSV output.
Allow Parallel Function Calling	Allows supported functions to be called in parallel.
Custom DateTime Implementation	Uses the Project's custom date and time implementation instead of the standard Agent handling.
No Default Instructions	Prevents ioLoop's default Agent instructions from being included.

Select Save within this section after changing its values.

System Instructions

System Instructions should establish what the Agent is expected to do and the limits within which it should operate.

A useful instruction set can cover:

• The Agent's role and audience.
• The topics or workflows it supports.
• When to use particular Knowledge Sources.
• Information it must not infer or disclose.
• When it should ask for clarification.
• How it should report uncertainty or tool failures.
• Whether a user must confirm a consequential action.
• The desired response style or output conventions.

Avoid relying on instructions as the only security boundary. Instructions can guide model behavior, but client Agent access, Database permissions, Function authorization, and external-service controls must enforce the applicable boundary.

Advanced Model Parameters

AI Model Parameters accepts a JSON object for advanced users. Values such as the model selection or temperature are provider-specific.

Use this field only when:

• The selected provider documents the option.
• The value is valid JSON.
• The selected model supports the requested behavior.
• You have tested how the change affects quality, latency, and usage.

Do not assume an option available for the current OpenAI provider will apply to future providers. Unsupported or invalid options can prevent initialization or cause a run to fail.

Allow Running Code

Enable Allow Running Code when the Agent needs supported model-side code execution or needs to generate artifacts such as charts, images, or CSV files.

Code execution can create generated files in Project Cloud Storage. Review and delete those files under Manage Usage when they are no longer required.

Leave this option off when the Agent does not need it. Enabling a capability does not mean every response should use it.

Allow Parallel Function Calling

Enable Allow Parallel Function Calling when independent Function tools can safely run at the same time and the selected model supports parallel calls.

Parallel execution can reduce response time, but it also changes operational behavior. Do not use it for functions that:

• Must execute in a strict order.
• Modify the same record or external resource.
• Depend on the result of another function.
• Can produce duplicate or conflicting side effects.
• Could exceed provider or external-service limits when called concurrently.

Function implementations must remain safe when the model requests more than one call.

Custom DateTime Implementation

Enable Custom DateTime Implementation when the Project supplies its own date and time behavior for the Agent.

Use a consistent timezone and clearly define how relative phrases such as “today,” “tomorrow,” or “next week” should be interpreted. Test date boundaries and user-specific timezone requirements.

No Default Instructions

Enable No Default Instructions only when you intentionally want to replace ioLoop's default Agent instructions with a fully custom instruction strategy.

Removing defaults can change expected behavior beyond tone. Test tool use, error handling, output formatting, and safety-sensitive workflows after enabling it.

Prompt Reinforcement

The Prompt Re-inforcement section adds short reminders to every turn.

Setting	Position	Intended Use
Per-Turn Prompt Re-inforcement Reminders (Prefix)	Before the current prompt	Restate a few important operating rules or context reminders.
Per-Turn Output QC (Suffix)	After the current prompt	Ask the Agent to check the quality or completeness of its planned response.

Keep reinforcement concise. The Project Editor recommends approximately three to six lines for the prefix and two to five lines for the suffix.

Use System Instructions for the Agent's enduring role and policy. Use reinforcement for a small number of requirements that should be reconsidered on every turn. Duplicating a long instruction set in both locations consumes context and can make behavior harder to maintain.

Examples of suitable reinforcement include reminders to:

• Verify required inputs before calling a Function.
• State when a source does not contain the requested information.
• Avoid treating caller-supplied context as authenticated identity.
• Check that a structured response includes all required fields.

Select Save within the section after making changes.

Add Knowledge Sources

After the provider and instructions are configured, add the sources required by the Agent.

1. Expand Knowledge Sources (Files, Databases, Functions, etc).
2. Select Add.
3. Choose a source type.
4. Configure its description, permissions, schema, Connection, or tools as applicable.
5. Test whether the Agent selects the source only when appropriate.

See Knowledge Sources.

Configure the Prompt Library

Use the Prompt Library to give users reusable starting prompts grouped by category. Prompt Library entries assist the user; they do not replace System Instructions or grant additional Agent permissions.

See Prompt Library.

Configure Client Access

Return to the AI Agents list and select Access (Security) for the Agent. Grant Execute access only to the Project groups that should be able to access the Agent from the client through an AI Agent Widget.

For Public, All Users, custom groups, Admin, and role levels, see User Groups. To create the Project Users who receive those memberships, see Users.

The Project Editor warns before Public access is granted. Public Agent access should be used only when the Widget experience, Agent knowledge, functions, table operations, and external tools have all been designed for unauthenticated client use. Review Custom Functions that access the Database directly and every Connection Knowledge Source: an inadequately protected Function can expose trusted server operations, while a Connection tool can act through its stored profile.

These Agent access settings do not govern trusted server-side calls from Cloud Flow. A Background Task or another AI Agent module can invoke the Agent regardless of its client access settings. For a Web Hook, the Web Hook's own Access (Security) settings determine who may call the endpoint; after that check succeeds, the Web Hook can invoke the Agent regardless of the Agent's Access (Security) settings.

Client access and operation authorization are also separate. A Widget user who may access an Agent can still be prohibited from a particular record or action. Likewise, trusted Cloud Flow must still validate the specific data and external operations it performs.

Configuration Changes and Chat History

Existing chat messages can continue to influence later responses. After changing instructions, model parameters, Knowledge Sources, or tool behavior, an old conversation may not demonstrate the new configuration cleanly.

For a controlled test:

1. Save the configuration change.
2. Start a new chat or clear the Agent's chat history when appropriate.
3. Run representative prompts again.
4. Review Run Logs for tool selection and errors.

Clear Chat History deletes history for all users of the Agent. Use it deliberately. See Managing and Testing AI Agents.

Configuration Checklist

Before making an Agent available:

• The AI provider Connection is configured and tested.
• System Instructions define a clear responsibility and boundaries.
• Advanced model parameters are valid and necessary.
• Code execution and parallel function calling are enabled only when required.
• Knowledge Source descriptions are clear.
• Table modification permissions are no broader than necessary.
• Every Custom Function has a matching implementation.
• Function implementations validate inputs and authorize sensitive operations.
• MCP and Connection tools expose only intended capabilities.
• Access (Security) matches the intended AI Agent Widget audience.
• Web Hooks that invoke the Agent have their own appropriate Access (Security) settings.
• Widget and headless invocation paths have both been tested where applicable.
• Failure, timeout, duplicate-action, and provider-usage behavior has been considered.

For the Agent's Cloud Flow, see AI Agent Cloud Flow. For invocation patterns, see Invoking AI Agents.