FruxonDocs

Core Concepts

The mental model behind Fruxon — how agents, revisions, tools, and runs fit together

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, API keys, 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:

NodePurpose
Entry PointDefines the typed inputs your agent accepts.
Agent StepAn LLM call with a prompt, optional tools, optional structured output.
Exit PointShapes the agent's response — what gets returned to the caller.

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, number, boolean, object, array. Reference them anywhere in a prompt or tool config with placeholder syntax:

  • {{input.topic}} — an entry parameter
  • {{step.summarize.output}} — output of a previous step
  • {{secret.STRIPE_KEY}} — a secret from your organization

Placeholders are how data flows. They're also how Fruxon knows which nodes depend on which — connections are derived, not drawn.

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 storage that survives across conversations. The agent reads and writes memory through tools (memory_write, memory_search, memory_delete). 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. Integrations live at the organization level and are reused across agents. Each integration exposes one or more tools that an agent can call.

Integrations →

Connectors

Inbound channels that route end-user messages to an agent. Slack, Microsoft Teams, Telegram, WhatsApp, Discord — any of them can deliver a user's message to your agent and forward the response back.

Each connector has a policy: open access, or onboarding-managed (new users wait for approval).

Connectors →

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 a sequence of runs that share state for a single end-user, typically delivered through a connector. Sessions are summarized automatically as they grow so context windows stay manageable.

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 roles (Admin, Editor, Viewer). Roles control who can edit, deploy, view traces, manage billing, and invite teammates.

Team →

Authentication

Two ways to talk to Fruxon programmatically:

  • Firebase JWT — used by the web app for human users
  • API keys — organization-scoped tokens for server-to-server access (X-API-KEY header)

End-users on connectors don't authenticate to Fruxon directly — the connector's own auth is 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. Connectors and API calls route real traffic to the deployed revision.
  7. Every run generates a trace and contributes to cost, viewable in Monitoring 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.

On this page