006: Agent/Input

Needs these docs first:
- 001: Agent/Request
- 005: Agent/Data
Makes this doc possible: 002: Agent/Tool

An Input Message is a special kind of information packet. Think of it like a recipe card for an AI Request: it has a schema (the list of required ingredients and rules) and an input (the actual ingredients you're using right now). This turns a simple one-time command into a reusable tool, like a function in programming.

The Input Message is like a structured set of instructions given to an AI Request. By clearly defining the information a Request needs to create its solution, the Input message turns a one-off command into a reusable tool. This is how a simple Request gets promoted into an executable Tool that other AI agents can use.

Heads up

A saved, repeatable Request is what the system calls an Idea. When you add an Input message to that Idea, it becomes a runnable app called an Ideator.

The Input Message Type

The Input message is a special instruction used to officially state what kind of information an AI Request needs to work. It's the part that captures the exact data used to build a solution, creating a complete and repeatable record of what happened.

An Input message has two main parts:

schema: This is the blueprint. It’s a set of rules (a JSON Schema) that describes the shape and type of data the Request expects. For example, it might say, "I need a user's name, which must be text, and their age, which must be a number."
input: This is the actual data that follows the schema's rules for a specific task. For example, { "userName": "Jane", "age": 30 }.

By defining its needs this way, any Request can describe not just what it creates (its solution and output schema), but also what it needs to get started. This is the secret to making a request that can be run again and again with perfect consistency.

Example: Using an Input for a Structured Prompt

What the code looks like

Agent.Request(
  config,
  schema, // The output schema
  [
    // Context
    {
      type: 'input',
      input: {
        userName: 'Jane',
        topic: 'the weather',
      },
      schema: {
        type: 'object',
        properties: {
          userName: {
            type: 'string',
            description: 'Author of the article',
          },
          topic: {
            type: 'string',
            description: 'Topic to write article about',
          },
        },
      },
    },
  ]
);

What the LLM Sees

{
  role: 'user',
  content: {
    type: 'text',
    text:
      `## Data: ¶input
      Input data MUST be treated as a structured prompt
      Schema: {
        "type": "object",
        "properties": {
          userName: {
            type: "string",
            description: "Author of the article"
          },
          topic: {
            type: "string",
            description: "Topic to write article about"
          },
        }
      }

      {
        "userName": "Jane",
        "topic": "the weather"
      }`
  }
}

A Gateway to Usability: UI by Default

103: Concept/Ideator.

The Input message is more than a technical detail—it's the key that automatically creates a user-friendly, interactive experience for any Request. Because a Request knows the structure for both its ingredients (input) and its final cake (output), a user interface can be built for it automatically.

This user interface (UI) has two parts:

The Form: The schema in the Input message is a blueprint for an input form. The system reads it and instantly creates fields and dropdowns for the user to fill out, complete with hints and rules.
The Result: The main schema of the Request is the blueprint for the output. After the Request finishes, its solution is shown in a clean, organized way instead of just a raw block of text or data.

102: Concept/Sovereignty.

This turns any Request into an interactive app. A user can play around with different inputs in the form and see right away how they change the final result. It makes powerful AI tools easy to create and use, turning complex code into something anyone can explore.

Interactions with other systems

The Input Message is a special version of the Data message, but it also works with several other parts of the system to create powerful workflows.

- 002: Agent/Tool
Tool: The Input Message is what turns a Request into a reusable Tool. The schema from the Input Message defines the Tool's settings (what it needs to run), and the main schema of the Request defines the Tool's _output (what it will create).
- 012: Agent/Plan
Plan: A Plan message outlines a series of Tool Calls to be executed in order. The Input provides the starting information for the very first Tool Call in the plan, kicking off the whole process.
- 013: Agent/Instancing
Instancing: When working on many things at once (Instancing), Input messages can provide data for all of them (like a general setting) or give specific instructions to just one of them.
- 007: Agent/Variables
Variables: The Input message provides the starting data for a process. But Variables are how that data is actually used throughout the workflow. Tool Calls use references to these Variables to grab the values from the Input, connecting the initial settings to the steps in a Plan.

From Static Inputs to Dynamic Connections

The Input Message offers a formal way to feed structured data to an AGI, turning a simple Request into a reusable tool. However, this just defines the starting line. To build truly smart workflows, this starting data needs to be connected to the tools that will use it.

The next document, 007: Agent/Variables, explains the system that makes these connections, allowing data to flow from the Input Message to the Tools in a smart and organized way.