Creating Agents

Create the agent

Every agent belongs to an Application. Open the Application's Agents page and click New Agent.

• Name — what teammates and API callers will see. Be specific (Support Triage beats Bot 3).
• Application — the Application the agent belongs to. With only one Application, it's picked for you; with several, it starts on the one you're in.

Click Create agent. You land in Studio, where the agent is one form. Write the agent's description alongside its instructions: what the agent does, when to use it, and what it expects as input. The description shows up in the API schema and to workflows that run the agent.

Define inputs

Under Instructions → Parameters, click Add parameter for each input the agent needs.

• Name — used as {{param.<name>}} in prompts. Use snake_case.
• Type — STRING, INTEGER, FLOAT, BOOLEAN, OPTION, JSON, STRING_ARRAY, DICTIONARY, and others. Match what callers will actually pass.
• Required — fail fast if missing, or let the agent handle the absence.
• Default — for optional inputs that have a sensible fallback.
• Description — appears in the API schema and to workflows that run the agent.

Keep the input surface minimal. Most agents have 1–4 parameters; more is usually a sign of an ambiguous role.

Wire LLM configs

Open the AI Providers tab to connect at least one provider account (OpenAI, Anthropic, Google, …) — this is the credential layer. Then open LLM Providers at the tenant level and publish one or more configs (each bundles a provider, model, and generation params under a name like summarizer-fast or analyst-careful). The agent picks a config rather than inline parameters.

• AI Providers — provider credentials
• LLM Providers — tenant-scoped configs you'll pick in the agent's form

Write the instructions and pick a model

Fill in the rest of Instructions, then Model & capabilities:

• System Prompt — sets the agent's behavior and constraints.
• Input Prompt — the per-run message, usually full of placeholders against the parameters.
• LLM Config and Model — pick a published config from the LLM Providers picker. Pick the cost / quality / reasoning mode this agent's job needs; add Fallback providers for when the primary won't answer.

System: You are a research analyst. Write concise, factual briefings.
Input:  Write a one-page briefing on: {{param.topic}}

If one agent's prompt starts covering several unrelated jobs, split it into separate agents and combine them.

Decide on tools, memory, sessions, knowledge

This is where most of the design effort goes. Each is a section of the agent's form:

• Tools / Skills (Model & capabilities) — does the agent need to do anything (call APIs, query DBs, run code, send messages)? See Tools & Skills.
• Knowledge (Model & capabilities) — does the agent need to retrieve from documents? Click Add knowledge base or Add asset. See Assets.
• Memory (Memory & context) — does the agent need to remember things across conversations? See Memory.
• Session & context (Memory & context) — does the agent need conversational history (multi-turn chat)? See Sessions.
• Judge / Quality check (Output & quality) — does the agent need an LLM-as-judge to score its output at runtime, optionally retrying on low scores? See Inline Judge.
• Output format (Output & quality) — does the caller need a specific JSON shape? Pick JSON schema and define it instead of parsing text.

Combine with other agents (optional)

For jobs that span multiple distinct concerns, build each concern as its own agent and run them together in a workflow.

Combining Agents →

Shape the output

By default the agent returns the model's reply as free text. When callers need fields rather than prose, open Output & quality → Output format and pick JSON object or JSON schema:

{
  "type": "object",
  "properties": {
    "briefing": { "type": "string" },
    "key_players": { "type": "array", "items": { "type": "string" } }
  },
  "required": ["briefing"]
}

The output shape is what API callers and workflows see. Stable output shapes let downstream code stay simple.

Test

Use Test chat on the right. Provide sample inputs covering:

• The happy path
• An obvious edge case (empty string, very long input, malformed object)
• Anything tricky from your domain

Watch the trace. Confirm placeholders resolved, the right provider was called, tools fired when expected, and cost/latency are reasonable.

Testing →

Evaluate

Studio saves your edits to a draft as you type. For anything customer-facing or business-critical, run an evaluation of the draft against a small golden dataset before you deploy.

Evaluations →

Deploy

Click Deploy. Say in a line why you're making the change; Fruxon saves the draft as a new revision, runs its pre-deploy checks, and makes it live. The agent is now reachable via:

• REST API — POST /v1/tenants/{tenant}/agents/{agent}:execute (API reference)
• Python SDK — see Python SDK
• Agent Network — triggers and participants for Slack, Teams, Telegram, Twilio, GitHub, email, and approval flows (Agent Network)
• Workflows — as an Agent step in any workflow in your organization

Roll back any time by deploying a previous revision.

Deployment →

Set guardrails

Before real traffic hits, configure:

• Budget — monthly cap and alert thresholds (Cost & Budgets)
• Participant access — approval queue for unknown or unbound senders (Access Requests)
• Sandbox mode — for any database or sensitive integration (Sandbox Mode)