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 a configured AI workflow. It has:

• A flow of steps (defined visually in Studio)
• Parameters it accepts as input
• Tools it can call (integrations, sub-agents, code, memory)
• Knowledge attached to it (files, data sources)
• AI providers wired to its steps
• A revision history — every save is captured immutably

Agents range from a single LLM call to multi-step orchestrators that loop, branch, call sub-agents, and escalate to humans.

Studio

The visual canvas where you build an agent. Drop nodes, write prompts, connect tools and knowledge — Fruxon wires the dataflow for you based on the placeholders you write.

Workflow & Nodes

A workflow is the graph inside an agent. Three node types form the spine of every agent:

You add as many Agent Steps as the workflow needs. Steps can run in sequence (later steps reference earlier outputs) or in parallel (if they have no shared dependencies).

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}} — an entry parameter
• {{step.summarize}} — the output of a previous step
• {{secret.STRIPE_KEY}} — a secret from your organization
• <file:…> — an attached asset, inserted from the prompt editor's asset picker

Placeholders are how data flows. They're also how Fruxon knows which nodes depend on which — connections are derived, not drawn. In Studio you insert them from a menu rather than hand-typing, so names always resolve.

Tools

Anything an agent step 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
• Sub-agents — other agents in your organization, callable as tools
• 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.

Sub-agents

Any agent can be called as a tool by another agent. This is how you build complex systems: a top-level orchestrator decomposes a task and delegates to specialized sub-agents.

Sub-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 save produces a revision — an immutable snapshot of the agent's full configuration. 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 monthly budgets per agent with alert thresholds and hard caps 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 individual agents is layered on top through collaborator roles — Viewer, Editor, or Admin — set per agent, 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 design its flow in Studio, with typed parameters, steps, and placeholders.
3. You give it tools via integrations, sub-agents, 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.