Platform Overview

AI agents that finish real work in your systems, and ask the person who owns it when something doesn't add up. Fruxon gives every agent a place in your org chart: a lane, people it can ask, limits on what it may touch and spend, and a record of everything it did.

Where a capability has its own guide, its paragraph links to it.

At a glance

1. The org chart: who the agent answers to

Ask the owner, then finish the job. Instead of guessing, the agent asks the person whose expertise matches, from the Directory, waits a traced and costed wait, then finishes the job in Shopify, Zendesk, or the CRM. A consult pin sends a given topic to a named person every time. If nobody answers, the ask falls through to the next person on the list. See Directory and CLI → Capabilities & consult pins.

Escalation to a named operator. When the agent can't finish, it hands the conversation to an operator, or to a ladder of them, that you configure per Application. The person takes over, and hands it back when they're done. See Applications → Human escalation.

Approval before action. Any tool can sit behind an approval gate: the call pauses before it runs, the approver sees the exact arguments, and a rejected call never executes. The gate is enforced outside the model, so a prompt injection can't talk past it. Who approves is a slot you bind to a person without touching the agent, and every decision lands in a tamper-evident audit trail. See Human approval, Agent Network → Human approvals, and Approval Auditing.

Autonomy that widens as it is earned. Start with the agent recommending and a person confirming every action. Loosen one gate at a time as the audit trail shows it can be trusted, per Application, without a new revision.

A teammate in the group chat. The agent sits in a Slack channel, a Teams channel, or a Telegram group and speaks only when addressed, or only when a relevance check says the message is for it. You can see how often it stays silent and what the check costs. See Agent Network → Reply policy.

Unknown senders knock first. Someone new who reaches an agent becomes an access request, not a silent new contact. An operator approves or rejects, and the Directory stays the people you chose. See Access Requests.

One person, every channel. A person in the Directory carries every address they're reachable at (Slack, WhatsApp, Telegram, a phone number) and every account that identifies them elsewhere (GitHub, Jira, Linear). The agent knows that benf1985 on Jira and bx_ntd on GitHub are the colleague it talks to on Slack. See Directory.

It remembers the person, not the chat. Memory is keyed to the Directory record, so what the agent learned about a customer on Slack is there next week on Telegram. Memories can be listed, edited, and erased per person. See Agent Memory.

Many customers, one agent. Enroll one agent to serve many end-customers, each as its own environment with its own cost, error rate, latency, and run history. Built for resellers, agencies, and multi-tenant products. See Environments.

2. Back-office work that finishes

Proactive, not only reactive. The agent listens for events from the systems you already run (GitHub, Jira, Linear, a schedule), filters them with rules you write without code, and decides which ones deserve a person. Those it brings to the team member who owns that area, with what it found attached. See Agent Network → Triggers.

Every item accounted for. Point an automation at a mailbox, a tracker, or a sheet, and every record becomes an item in the Work ledger. Each one is entered once, moves through the stages you declared, and ends finished, set aside with a reason, or parked for a person. Open the Work tab and see what came in, where each item is and why, what it cost, and what is stuck. See Automations.

One agent per stage. Extract, ask, file, report: each stage is a small agent with its own instructions, tools, and spend, instead of one prompt that does everything. Routing rules send an item down the right path: not in the system, needs review, ready to file. See Automations → Stages.

Ask once per sitting. When a stage needs a person, the items gather and the person gets one question, on one sheet, with a deadline. The answers flow back to the items. The process never waits inside a run, so a five-day wait costs nothing and breaks nothing. See Automations → Ask a person stages.

Nothing lost, nothing done twice. An item is claimed by one worker at a time, every stage is recorded as it completes, and a failed attempt is retried with backoff a set number of times before it is parked. Every effect on an outside system is recorded before and after the call, so a retry knows whether it already happened. A record the ledger has already finished is not processed again. An operator re-drives a stuck item, sets one aside with a reason, or corrects its data, from the Work tab, not the database. See Automations → Items and their states and Re-drive and ignore items.

Batch work over a list. A pipeline maps an agent over a Google Sheet, a tracker, or a CRM list: one isolated run per record, each with its own trace, cost, and retry boundary. Put it on a schedule and cap the spend per run. See Collection Pipelines.

Priced by what it finishes. Because every outcome is counted, an automation can be billed per filed policy or per invoice, not per token.

3. Learning: it gets better from the work it does

Configuration that learns from execution. Fruxon reviews each conversation after the fact and turns what it finds into cards an admin approves with one click: a missing tool, a prompt change, a new instruction. Nothing changes until a person says so. See Improvements.

A knowledge base that writes itself from your conversations. A managed source reads your support conversations, extracts articles, and holds the risky ones for review: personal data, low confidence, a rewrite of something that already existed. Knowledge gaps the reviewer finds in agent conversations land in the same queue as drafts. Fully automatic publishing has to be earned through a calibration pass. See Knowledge Sources and Knowledge Bases.

A judge on any step. An inline quality check scores a step's output against your criteria and can send it back with feedback for another try. Its verdicts show up in the trace and roll up into the agent's quality numbers. See Inline Judge.

4. Ship with confidence

Evaluate before you deploy. Build a golden dataset, define the metrics, and run a revision against it before it sees traffic. A real production run can be promoted into a regression test in one step. See Evaluations and Observability → Tagging runs into datasets.

Revisions, deploy, roll back. Every change to an agent is a revision. Compare two, deploy one, roll back in a click, or exercise a revision that isn't deployed. See Versioning.

Rehearse against a simulator. Sandbox mode runs the agent against the vendor's own sandbox or Fruxon's simulator, or reads from production and writes to the simulator. The CLI simulates a whole network, with participant turns, trigger fires, consults, and approvals, before anything deploys. See Sandbox Mode and CLI → Sandbox.

5. Control: what it may see and spend

Sensitive values it never sees. API keys, tokens, and passwords live as Secrets and appear in the agent's tools as placeholders. The value is swapped in at the moment of the call and scrubbed from the tool's reply, so it never enters the prompt, the trace, or the logs. Credentials are typed by a person in the dashboard or through a one-time link, never through the agent. Secrets marked financial, health, or regulated get fail-closed audit: if the audit can't be written, the call doesn't happen. See Secrets.

A ceiling on what a stage may do. Each stage of an automation declares whether its agent may only read, or may also write, and the platform refuses a tool call above that ceiling no matter what the model decides. See Automations → Process stages.

Spend limits where the money goes. A monthly budget per agent, with production and dev counted separately, that alerts at a threshold or hard-stops at the cap. A spend limit per automation per day, week, or month. A dollar ceiling per pipeline run, and a per-item stop-loss so one stuck record can't burn the budget. Cost is split per customer, so you can see who spends what. See Cost, Budgets & Credits → Spend limits and Collection Pipelines → Run policy.

Roles, not blanket access. Organization roles set a baseline, Application collaborators grant access to one Application and what it owns. Tokens are scoped, expire, rotate, and every issuance is audited. Service accounts carry production workloads so a script never runs on a person's login. See Team & Roles, Tokens, and Service Accounts.

Sign in through your identity provider. A workspace connects its SAML identity provider, verifies its email domains over DNS, and its people sign in through the provider they already use. Sessions expire on the schedule you set and re-authenticate through the provider, and every sign-in is recorded in a ledger. See Sign-in & SSO.

6. Operate: every run accounted for

Every run is a trace. Each step shows its tokens, cost, wait time, and any approval it paused for. Filter the history to one customer, one failure, one week. See Observability.

Agents you didn't build on Fruxon, in the same view. Agents on LangGraph, CrewAI, or your own framework push OpenTelemetry into the same trace and metrics pages. See Observability → External agents & OpenTelemetry.

Every failure an alert. Alerts fire for a failed run, a budget threshold, a pending access request, and an integration credential that stopped working. They're throttled, so a storm sends one email, not a thousand. Credential health is tracked from real token refreshes, so you hear about a revoked OAuth grant before the failure log fills up. See Observability → Alerts and Integration credential health.

Evidence for the model-risk committee. The questions a model-risk framework asks, such as Bank of Israel Directive 369, map onto things the platform already keeps: agents and their revisions are the inventory, golden datasets and evaluations are the validation, the judge and quality alerts are the ongoing monitoring, revisions with deploy and rollback are the change control, approval gates and their audit trail are the human oversight. Each is exportable, with who did what and when.

7. Where it runs

Your region, your keys, your cloud. Data region and inference residency are two separate controls. The region pins the database, files, backups, keys, and processing, and there is no path to move it. Run on Fruxon's managed cloud, in a dedicated single-tenant project, or inside your own VPC or data center with your own keys. Credentials are encrypted per tenant, with keys wrapped by a cloud KMS you can own, and each integration's outbound traffic can be pinned to a country. See Hosting & Data Residency.

You decide where prompts go, and the platform proves it. Inference residency restricts which providers an agent may call: any provider, only your own cloud account, or only models served from a named region. The rule is enforced when a config is published and again before every run, per model, and every change is audited. Where a model is served in-region, in the US and the EU, the in-region setting is honoured to the letter. Elsewhere, the setting records and enforces exactly which cloud and region your prompts reach. See Hosting & Data Residency → Inference residency.

Any model, mixed per step. OpenAI, Anthropic, Google, or your own Vertex AI, Bedrock, or Azure account. A cheap model routes and a strong one drafts, inside one agent. Provider configs have draft, publish, and rollback like everything else, so a model change is as reversible as a prompt change. See LLM Providers and AI Providers → Mixing models for cost and quality.

8. Build and connect

More than 60 integrations, and MCP both ways. Shopify, Zendesk, HubSpot, Salesforce, Jira, GitHub, Slack, Microsoft 365, Stripe, SAP, databases, and more. An agent can call MCP servers, and any Fruxon integration can be published as an MCP server, so Claude Desktop or Cursor uses your Salesforce with your credentials, Fruxon's sandbox, and Fruxon's traces. See Integrations and MCP Server.

Same agent, every channel. Slack, Teams, Telegram, WhatsApp, SMS and phone numbers, and a widget on your own site for anonymous or signed-in visitors. See Agent Network and Embed Widget.

Talk to your agent. In the Test lab you speak with the agent, in Hebrew or English, and it speaks back: it listens, answers first, says "one moment" while it looks something up, and stops when you interrupt. Every spoken turn is traced like a text one, down to what the caller actually heard.

Build from Claude Code or Cursor. The CLI and Python SDK speak an agent-mode contract, and the Fruxon plugin teaches Claude Code and Codex to write, test, and debug agents. Copilot in the dashboard edits an agent from a chat and imports agents you already have. See Claude Code & Codex, CLI, Python SDK, and Copilot.

No lock-in by design. An agent is a definition you can pull, diff, and version with the CLI. Models are yours, telemetry leaves over OpenTelemetry, and in a VPC deployment Fruxon has no standing access to anything you run. See CLI.

Skills and sub-agents. A skill bundles instructions, tools, and knowledge for one job and loads only when a turn needs it. Sub-agents compose as router to specialist, or as draft, approve, act. See Skills and Combining Agents.

Knowledge where the agent can reach it. Files, data sources, and tool outputs attach to any step, searched at run time. See Knowledge Base & Assets.

Support cases. Case lifecycle, requester eligibility, and continuation, switched on per Application, with the case tools handed to every member agent. See Applications → Capabilities.

Next steps

• Quickstart — build and run your first agent
• Core Concepts — the mental model: agents, tools, revisions, runs