Core Concepts

If you read just one page besides the quickstart, read this one. Everything else in the docs assumes the vocabulary below.

Organization

Your organization (also called a tenant in API contexts) is the top-level container. Everything — agents, integrations, assets, team members, tokens, billing — lives inside one organization, and is isolated from every other organization on the platform.

You can belong to multiple organizations and switch between them from the sidebar.

Agent

An agent is one definition of an AI worker, edited as a form in Studio. It has:

• A model — the LLM config and model it runs on
• Prompts — a system prompt and an input prompt
• Parameters it accepts as input
• Tools and skills it can call (integrations, code, memory)
• Knowledge attached to it (files, data sources)
• Settings for sessions, memory, escalation, output format, and quality checks
• A revision history — every saved version is kept immutably

On each run the agent reads its input, calls tools in a loop until it has an answer, and replies. It can remember the conversation, consult a person, or escalate to one.

Studio

The editor where you build an agent. It shows the agent's definition as one form: parameters and prompts, the model, tools, skills, knowledge, and the settings that shape how it behaves. A test chat sits next to it.

Agent Studio →

Workflows

A workflow is a graph you build on a canvas: Agent steps that each run an existing agent, tool steps, and the order between them. Use one when a job needs several agents and tools to run in a set order. An agent itself has no graph.

Parameters & Placeholders

Inputs are typed — STRING, INTEGER, FLOAT, BOOLEAN, OPTION, JSON, STRING_ARRAY, and DICTIONARY, plus ASSET and TOOL for richer inputs. Reference them anywhere in a prompt or tool config with placeholder syntax:

• {{param.topic}} — a parameter
• {{sender.name}} — a field of the person who sent the message
• {{secret.STRIPE_KEY}} — a secret from your organization
• <file:…> — an attached asset, inserted from the prompt editor's asset picker

Placeholders are how data reaches the prompts. In Studio you insert them from a menu rather than hand-typing, so names always resolve.

Tools

Anything an agent can do in addition to talking. Comes in several flavors:

• Integration tools — pre-built actions on third-party services (Salesforce, PostgreSQL, Slack, Tavily, etc.)
• API tools — your own REST endpoints, imported from OpenAPI specs or configured manually
• Code execution — run Python in a secure sandbox
• Memory tools — read/write the agent's persistent memory
• Built-in tools — date/time, JSON helpers, chat user info, file ops, etc.

Tools & Skills →

Skills

A skill is a reusable bundle of instructions, tool references, and knowledge. Attach a skill to an agent and the agent gains an expertise — say, "knows how to draft sales emails using HubSpot data and our brand guidelines." Skills make it easy to share capability across agents without copy-paste.

Combining agents

Bigger jobs are split across several focused agents. A workflow runs them in the order you draw, each agent's output feeding the next; an agent can also fan out parallel sub-tasks of its own.

Combining agents →

Memory

Per-agent persistent notes that survive across conversations. Each memory is a title, a body, and optional tags; the agent reads and writes them through tools (memory_write, memory_search, memory_delete) and retrieves by keyword search. Use it for facts the agent should remember about a user, project, or domain.

Memory →

Knowledge Base & Assets

Files and data sources attached to an agent for retrieval. Documents are vectorized and made searchable — the agent semantically retrieves the relevant chunks at runtime instead of stuffing the entire document into the prompt.

Sources include direct uploads (PDF, DOCX, etc.), Confluence, GitHub repos, web URLs, and more.

Knowledge Base →

Integrations

A configured connection to an external service — an OAuth grant to Google Drive, a Salesforce credential, a database connection string, a Slack bot token, or a Telegram bot. Integrations live at the organization level and are reused across agents. Each integration can expose tools, triggers, and channels.

Integrations →

Agent Network

Tenant-level wiring around agents:

• Triggers are schedules, webhooks, or integration events that fire agents.
• Participants are people, groups, or AI agents that can talk to agents through channels.
• Access requests are proposed participant/binding additions raised when an unknown sender tries to reach an agent.
• Conversations are observed provider threads, such as Slack channels, Telegram chats, Teams threads, or phone-number conversations.

Agent Network →

Revisions

Every version you save is a revision — an immutable snapshot of the agent's full definition. Studio saves a version when you deploy; until then your edits live in a draft. You can compare, deploy, or roll back to any revision. The deployed revision is what handles production traffic; you can always edit and test new candidate revisions without affecting it.

Versioning →

Runs, Traces, and Conversations

A run is one execution of an agent. Every run produces a trace — the full record of inputs, prompts, tool calls, intermediate outputs, tokens, latency, errors, and cost.

A conversation is an observed provider thread or end-user session, typically delivered through an Agent Network participant channel. Sessions are summarized automatically as they grow so context windows stay manageable.

Environments

The end-customer an agent serves. Managed in the Directory as a record with a slug, contacts, and an optional logo — you can enroll an agent onto one to answer that customer's channel, and every run tagged with its slug (acme_corp, globex, …) splits cost and analytics per customer. Not a deployment stage.

Environments →

Evaluations

A way to test agent quality systematically. Run a candidate revision against a golden dataset of inputs (with optional expected outputs), have an LLM judge score each result against criteria you define, and compare against the deployed baseline before promoting.

Evaluations →

Budgets & Cost

Every agent and every run has a tracked cost — token spend across all LLM and tool calls. Set daily, weekly, and monthly spend limits per agent, with alert thresholds, that block new runs once reached, so a runaway loop never becomes a runaway bill.

Team & Roles

Organizations have members with one of two org roles: Admin or Member. Admins manage billing, members, and org-wide settings. Access to agents is layered on top through collaborator roles — Viewer, Editor, or Admin — set on the Application that owns them, controlling who can view traces, edit, and deploy.

Team →

Authentication

Two ways to talk to Fruxon programmatically:

• Firebase JWT — used by the web app for human users
• Tokens — organization-scoped, scoped access tokens for server-to-server access — personal access tokens (fx_pat_) and service-account tokens (fx_sat_), sent in the Authorization: Bearer header

End-users on channels don't authenticate to Fruxon directly — the messaging provider's identity and the participant binding are the source of truth.

Putting it together

1. You create an agent in your organization.
2. You fill in its definition in Studio: typed parameters, prompts with placeholders, and a model.
3. You give it tools via integrations, plus skills, memory, and knowledge.
4. You test it interactively, then run evaluations against a golden set.
5. You deploy a revision.
6. Agent Network triggers, participants, and API calls route real traffic to the deployed revision.
7. Every run generates a trace and contributes to cost, viewable in Observability and per-agent Conversations.
8. You iterate, deploy new revisions, roll back if needed.

That's the whole loop. Everything else in the product is a refinement of one of these pieces.