Applications

An Application is the shared boundary around a set of agents, the operators who back them, and the people they serve. It's how you scope a product or team: which agents answer, who they serve, what they're allowed to do, and where messages come in. Every workspace has a Default Application; create more to separate distinct products, teams, or customer sets.

Mental model

In the sidebar, each Application opens into the pages that belong to it:

Web address

Every page that belongs to an Application lives under its web address — a short, readable name in the URL:

/app/customer-support/agents
/app/customer-support/people

The web address is created from the Application's name when you create it (lowercase letters, digits, and hyphens; names in other scripts are transliterated), and it is unique within the workspace. Because it names the Application, a link you send opens the same Application for whoever follows it, and you can keep two Applications open in two tabs.

Pages that already name their own resource — an agent's studio, a workflow run — keep their own URLs and pick up the Application from whatever they load. The Inbox is workspace-wide and sits outside any Application.

Renaming an Application does not change its web address. The name is a label; the address is in every link anyone has already shared or bookmarked, so the two move independently. To change the address, edit App settings → General → Web address.

Overview

Overview is where an Application opens: how it's doing, and what needs you. In the header, the window control (7d, 30d, 90d, or All; 30d by default) sets the spend and performance numbers, and Files opens the Application's runtime files. Top to bottom, the page shows:

• Status chips: Running now (production runs in flight across the Application's agents), Waiting on human (approvals waiting on a decision, plus escalations waiting for a person), Access requests, and Spend for the window. Budget-blocked joins them when an agent is refusing every run because of its budget. Each chip opens what it counts.
• A warning when an integration credential, an LLM config, or an agent's budget needs attention, naming each one with a link to the fix.
• The setup checklist, while setup is unfinished (below).
• Awaiting a human, when Human escalation is on and someone is waiting: the conversations waiting for an operator, with Open full queue.
• Performance: Conversations and Cost / conversation, a Human-in-the-loop grid (escalation rate, time to human, active takeovers, and more) when Human escalation is on, a Trend chart, and an Automations summary when the Application has any. A conversation is one customer's messages, split wherever they went quiet for four hours. Test and debug-console runs don't count.
• Why conversations escalate, when Human escalation is on: the reasons agents gave in their own words, how those escalations ended, and a link to the latest conversation for each.
• Setup: chips counting the Application's agents and the people it serves, a chip per capability showing its state (see Capabilities), and the tools below.

Setup checklist. Until the Application can serve customers, Set up this Application to serve customers lists the steps in order, each with a button that takes you there. The Default Application never shows it.

Once the required steps are done, the checklist leaves the top of the page; Review setup in the Setup section shows it again.

Open debug console opens a sandbox session against one of the Application's agents. Pick which under Agent to test when there are several. Use Start from to send turns as a participant or to fire one of the agent's triggers. Replies are captured in the console, and nothing is delivered to real channels. View application map shows how the agents are wired to participants, triggers, and approval slots.

Agents

Agents shows the agents that belong to this Application, as cards. Every agent belongs to exactly one Application, chosen when it's created: New Agent creates one here, and in a workspace with several Applications the create dialog's Application field starts on the one you're in. Search, the Enabled filter, and tag filters narrow the list. Agents that Fruxon builds and maintains for a knowledge base are grouped under Managed by Knowledge, collapsed by default. Change those from the knowledge base or source that owns them.

There's no per-Application release pin. Which revision an agent serves is decided by the agent's own deploy. See Versioning.

Turning an agent on or off

To take an agent out of service without changing the agent, use the Application's admin page. In Mission control, click the gear (Manage) on the Application's row. Mission control appears in the sidebar once the workspace has more than one Application. The admin page's Agent deployment list shows each agent's state:

Turn off… asks how to stop:

• Let current work finish (the default) refuses new conversations, but anything already parked on a person can still be handed back and completed. Once nothing is left in flight, Fruxon switches the agent to Off by itself, within about five minutes. Resume turns it back on before then.
• Stop now refuses everything, including resuming work that's already parked. If conversations are waiting on a human, the dialog says how many, because stopping now abandons them.

Turn on puts an agent back in service. Either way, the agent itself and everything built in it are untouched.

People

People covers everyone the Application serves and works with, in three tabs: Directory, Roster roles, and Escalation.

Directory

One list of everyone with a relationship in this Application: the people and shared groups it serves, plus observers, advisors, and operators.

The filter chips are All, Customers (external and served), Internal (internal and served), Operators, Advisors, Observers, and Shared groups; a menu beside them filters by response mode. The Shared groups view adds a Reply policy column, set for each agent that serves the group. See Reply policy.

Add person or group picks a record from the Directory and gives it a Relationship: Participant (served by the agents) or Observer. Environment enrollment enrolls everyone in an environment at once, or offboards them. Each row's menu has View profile, Change relationship…, Escalation override… for people the Application serves (see Human escalation), Drain operator for operators, and Remove from application…. Someone you remove is treated as a new contact if they message again, and their conversations are kept. To keep someone out, block them instead.

Roster roles

Roster roles route work to whoever holds them. When an agent consults a role, or addresses a contact bound to one, this list decides who answers. A role an agent uses but nobody holds reaches nobody.

The filter chips are All, Unstaffed (used by an agent contact but held by nobody), and Used by agents. A warning above the list counts unstaffed roles, because deliveries and consults to them are refused until someone holds them. Add role creates a role with a name and an optional description. Delete clears a role everywhere it's named, including the tag on each holder's profile, which reaches every Application they're used in. You can't delete a role while an agent contact still routes to it.

Escalation

Who takes a hand-off, how it's delivered, and when the team is working. See Human escalation.

Configure

The rest of an Application's configuration is spread over its pages, each answering one question:

Capabilities

Capabilities gate what member agents may do:

• Support Cases — case lifecycle, requester eligibility, and continuation. Installing it makes the ticket/case toolset available to member agents. On the Overview it reads Not installed, Off, or Enabled.
• Human escalation — the switch for human hand-off. When on, member agents can escalate a live conversation to an operator on the ladder; when off, escalation is unavailable even if a ladder is configured. On the Overview it reads Ready only once it can actually hand off: on, with at least one active operator and someone on the ladder. Under Native handoff, on is enough. On but not ready reads Needs setup, and its tooltip names what's missing.

By default, unknown senders who try to reach an Application surface as access requests rather than being added silently. App settings → General → Who can reach this Application can instead ignore them or enroll them automatically.

Human escalation

Human escalation hands a live conversation from an agent to a person on your team. An agent can escalate only when all three of these hold, each read live:

• The agent has Escalate to human turned on (under Collaboration in its form). This gives the agent the escalate_to_human tool.
• The Application's Human escalation capability is on (above).
• There is someone to reach: an active operator on the ladder or in a per-customer override, or Native handoff on a channel with its own console.

You set who and how under People → Escalation. Edits there save automatically and apply right away; nothing is deployed.

Who can take over. Operators are team members from the Directory. Each has two switches: Available, which operators can also flip from their own channel by sending /away and /back, and Enabled, an admin drain. Escalation skips anyone who is away or disabled.

How the hand-off works. Pick a Delivery mode:

Under Native handoff, While a teammate is being reached sets when the agent goes quiet. Step back immediately (the default) stops it replying as soon as the chat is queued. Keep helping until a teammate takes over keeps it answering while the chat waits. Once a teammate takes the chat in the console, the agent is muted either way. If a teammate never answers can hand a taken chat back to the agent after 24 hours of the customer waiting. It's off by default, and you're notified either way.

Order they're tried. The ladder is a list of tiers, tried in order. Fruxon pages the first operator it can reach in ladder order, skipping anyone away, disabled, already in another takeover, or unreachable. To give one customer dedicated operators, open their row menu in People → Directory and choose Escalation override…. Preferred tries those operators before the Application's ladder; Exclusive uses only them.

The same tab also holds After a hand-back (Follow up and close the ticket automatically when a teammate hands a conversation back without resolving it), When the team is working (see Working hours), and Default escalation reason, which is used when an agent escalates without giving a reason.

During a Bridge takeover

The agent tells the customer it has asked a teammate to join. It never names anyone or says they have already arrived. After that, Fruxon messages the customer directly with fixed notices in the customer's language (English, Hebrew, Arabic, or Russian, with English as the fallback): one when the operator's first reply goes through, and one when the operator hands the conversation back with /done. No model runs while the bridge is open. Both sides of the exchange are saved to the agent's history, so the agent picks up where the operator left off.

If an operator hasn't replied within 5 minutes, the next operator is paged. A takeover with no activity for 6 hours ends: the operator is told, and the agent takes the conversation back.

When nobody can be reached

If no operator is configured, or every operator is passed over, three things happen. The customer gets a fixed notice that nobody is free right now and someone will get back to them, the agent keeps the conversation, and the escalation appears under Inbox → Escalations → Awaiting a human for follow-up.

When the agent's turn fails

A turn that fails sends the customer nothing. When that happens, Fruxon escalates for the agent, running the same hand-off escalate_to_human would have run. The customer gets a fixed notice that a teammate will continue with them, or, outside working hours, that the team will continue once it's back. Nothing is sent if the conversation was already with the team, and the usual notice goes out if nobody can be reached. In a group chat, the notice goes to the group. The operator sees a generic reason saying the assistant hit an error; the customer's message isn't copied into it.

This has no switch of its own. It applies wherever the agent could have escalated itself: Escalate to human is on in the agent's current revision, the capability is on, and there is someone to reach. It covers only a message a person sent, and only once the failure is final. It doesn't apply to:

• A turn that will be retried, or a run refused because of license, budget, or credit limits.
• A disabled agent, or an agent that isn't active in the Application.
• A message from one of the Application's operators, a conversation the agent opened to consult or delegate, or a Test lab run.
• A reply the agent wrote that couldn't be delivered.

Working hours

Working hours tell agents when the team they escalate to is at work. You define them once in Settings → Working hours, and any Application can use them.

The list shows each schedule's zone, a summary of its week, and Working now or Off now. Changes reach agents on their next turn. You can't delete hours that an Application still uses, so detach them first.

To use a schedule, pick it under People → Escalation → When the team is working. The default, Always available, treats the team as reachable at any hour. Working hours change what agents say, not who gets paged: operators are still paged outside the hours.

What the agent is told. On every turn, an agent that can escalate gets a <working_hours> block in its context. It lists the team's weekly hours, any exceptions in the next 14 days, whether the team is working right now, and when that next changes, in local time with UTC alongside. Fruxon works out whether the team is working, so the model never does time-zone arithmetic. The block is left out when no hours are attached, when the hours never close, and when the person talking to the agent is one of the team's operators.

Escalating after hours. When escalate_to_human runs outside the hours, or inside the closing-soon window, the hand-off still goes through. The result tells the agent not to promise that a teammate will join shortly. Instead, the agent tells the customer that a teammate will pick it up when the team is back, and when that is. The notice for a failed turn changes the same way.

Outside working hours sets what the agent does with a queued chat while the team is off. It appears with Native handoff under While a teammate is being reached, and stays disabled until you pick working hours.

In the API, working hours are GET and POST on /v1/tenants/{tenant}/workingHoursSchedules, and GET, PATCH, and DELETE on /v1/tenants/{tenant}/workingHoursSchedules/{workingHoursSchedule}. These use the participants:read and participants:write scopes. A PATCH replaces weekly and overrides whole when you send them, and every response includes a status with isOpen and nextChangeAt. An Application's escalation routing is GET and PUT on /v1/tenants/{tenant}/networks/{network}/escalationPolicy. PUT replaces the whole routing, including workingHoursScheduleId and afterHoursConsoleMuteTrigger (ON_QUEUED, ON_ASSIGNED, or null to match working hours).