Creating Agents

Create the agent

In the sidebar, Agents → Create Agent.

• Name — what teammates and API callers will see. Be specific (Support Triage beats Bot 3).
• Type — Chat, Summarization, Recommendation, Analyzer, or Other. This is metadata for organization; it doesn't restrict capability.
• Description — what the agent does, when to use it, what it expects as input. This shows up to sub-agent callers and in the API schema.

You land in Studio.

Define inputs

Click the Entry Point node. Add the parameters the agent needs.

• Name — used as {{input.<name>}} in prompts. Use snake_case.
• Type — string, number, boolean, object, array. 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 sub-agent callers.

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). Each step will pick a config rather than inline parameters.

• AI Providers — provider credentials
• LLM Providers — tenant-scoped configs you'll pick from steps

Add the first Agent Step

Drop an Agent Step on the canvas and configure it:

• Name — referenced as {{step.<name>.output}} later. Short and meaningful.
• System Prompt — sets the agent's behavior and constraints.
• User Prompt — usually full of placeholders against inputs.
• LLM Config — pick a published config from the LLM Providers picker. Different steps can pick different configs to mix cost / quality / reasoning modes.

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

For most agents, start with a single step. Add more only when you need them.

Decide on tools, memory, sessions, knowledge

This is where most of the design effort goes. Each is per-step:

• Tools / Skills — does the step need to do anything (call APIs, query DBs, run code, hand off to sub-agents)? See Tools & Skills.
• Memory — does the agent need to remember things across conversations? See Memory.
• Sessions — does this step need conversational history (multi-turn chat)? See Sessions.
• Knowledge Base — does the step need to retrieve from documents? Attach assets via the Knowledge Base panel. See Assets.
• Quality check — does this step need an LLM-as-judge to score its output at runtime, optionally retrying on low scores? See Inline Judge.
• Structured Output — does the caller need a specific JSON shape? Define a schema instead of parsing text.

Compose with sub-agents (optional)

For workflows that span multiple distinct concerns, build them as separate agents and call them as sub-agents from a thin orchestrator.

Sub-agents →

Shape the output

Click the Exit Point node. Map fields from any step output, input, or asset:

briefing  ← {{step.briefing.output}}
sources   ← {{step.research.tool_calls}}

The exit shape is what API callers and sub-agent parents see. Stable exit shapes let downstream code stay simple.

Test

Hit Test in the toolbar (or ⌘/Ctrl + Enter). 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 →

Save & evaluate

Save (⌘/Ctrl + S) — that creates a revision. For anything customer-facing or business-critical, run an evaluation against a small golden dataset before deploy.

Evaluations →

Deploy

Open Revisions → Deploy → Confirm. The agent is now reachable via:

• REST API — POST /v1/tenants/{tenant}/agents/{agent}:execute (API reference)
• Python SDK — see Python SDK
• CLI — fruxon run, fruxon chat (CLI guide)
• Connectors — Slack, Teams, Telegram, WhatsApp (Connectors)
• Sub-agent calls — from any other agent 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)
• Connector access — onboarding policy if customer-facing (Access Requests)
• Sandbox mode — for any database or sensitive integration (Sandbox Mode)